From fuzzyman at voidspace.org.uk Tue May 1 01:58:34 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 01 May 2007 00:58:34 +0100 Subject: [IronPython] IronPython 2.0 Alpha 1 Released In-Reply-To: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <463682AA.60806@voidspace.org.uk> Hello Dino, Wow - this seems like a big deal. :-) Does IronPython 2 still support hosting multiple IronPython engines ? Thanks Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml Dino Viehland wrote: > > Hello IronPython Community, > > We have just released IronPython 2.0 Alpha 1. IronPython 2.0 will be > the first release of IronPython built upon a common dynamic language > runtime (DLR) as well as targeting version 2.5 of Python. These > release notes list what is new in IronPython 2.0, a brief overview of > the DLR, and what to expect from the 2.0 release. > > > One major focus during this release will be further improving our > conformance with CPython. We?ve already made several improvements, for > example one is that our type system no longer contains a hierarchy of > types: now type(type) is type. We have also fixed a number of issues > related to various statements such as imports and function definitions > inside of exec or eval. There have also been a number of other small > issues fixed that our users reported to us. > > IronPython 2.0 will also be the first major release to support 2.5 out > of the box. In IronPython 1.x, and in this initial alpha release, > users must enable this with a command line switch. During the 2.0 > release cycle we will flush out the remaining 2.5 features and > permanently enable this option. We will also start looking at > supporting v2.6 features via command line switch and start some > experimentation around the 3.0 features. In particular, we are excited > about looking at the new bytes and string types as well as formatting > options that we believe will fit nicely with .NET. > > IronPython 2.0 is also the first release built upon the Dynamic > Language Runtime: a shared runtime for dynamic languages on .NET. The > DLR both reduces the amount of work to create new dynamic languages on > .NET enables rich interoperability between dynamic languages, and > provides a shared module for consuming those languages from > applications. We are particularly excited about the ability to share > code across dynamic languages enabling users to share libraries > without worrying the particular language in which the library is > written. Over time, the DLR will expand and improve bringing language > developers more benefits from this shared infrastructure. We also look > forward to seeing a new era of programmable apps that can support a > wide range of options for end-users. > > When we started working on the DLR we initially used the IronPython > v1.0 code base. From there we extracted the core concepts that were > common to dynamic languages, generalized the concepts that were > specific to Python, expanded the framework to provide rich support for > other dynamic languages, and exposed all of the languages via a common > interface. Starting with IronPython 1.0 was an obvious choice because > it had already captured many of the best practices for building > dynamic languages on .NET and had done a great job leveraging many of > the underlying features of .NET. In IronPython 2.0 all of these best > practices are expanded and implemented with an eye on maximizing > forward compatibility with new features in .NET v3.5 such as LINQ and > extension methods. Moreover, the DLR exposes this functionality to the > language implementer via a small set of core concepts that all dynamic > language implementations can share. > > One additional change in this release is that we?re moving to use the > Microsoft Permissive License for IronPython 2.0. Our original release > of IronPython predated the Microsoft Permissive License, and so we > created a custom license specifically for Iron Python. After releasing > Iron Python, we created new Microsoft Shared Source licenses, > including the Microsoft Permissive License, to facilitate and > standardize source code licensing for appropriate Microsoft projects. > We believe our users appreciate consistency in licensing from > Microsoft. Therefore, because we are now using the more modern > Microsoft Permissive License where appropriate for similar current > source code releases, we feel we should offer IronPython under the > Microsoft Permissive License as well. > > Note because this is an alpha release there is also some missing > functionality that was formerly present in v1.0. This includes CodeDom > support, the static compiler that produced .NET assemblies, support > for creating strongly typed delegates to script code, as well as a > drastically changed hosting API. We will be bringing this > functionality back to future releases in the IronPython 2.0 series as > well many other improvements. > You can download IronPython v2.0 at: 2.0 Alpha > > > If you?d like more details about the DLR, Jim will be using his blog > to post design notes as they are written over the next couple of weeks > ? http://blogs.msdn.com/hugunin. > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dinov at exchange.microsoft.com Tue May 1 02:36:18 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 30 Apr 2007 17:36:18 -0700 Subject: [IronPython] IronPython 2.0 Alpha 1 Released In-Reply-To: <463682AA.60806@voidspace.org.uk> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Yeah, incase the release notes aren't obvious there's a bunch of things that go with this: IronPython in the web browser (IE, FireFox, and Safari - yes, there's Mac support as well) via Silverlight. There's an ASP.NET Futures which has also launched (linked from our home page on CodePlex), not to mention the DLR. Anyway, back to the hosting APIs :). They don't support multiple instances now but we still have an additional round of changes to go through w/ the hosting APIs. I'm not sure what will happen with that. I'm also not sure that we actively prevent creating 2 instances but I know we've made some spots singleton's that used to not be - therefore if you tried it you'd likely run into issues. Additionally the entire hosting API surface is also quite different. I have a version that wraps the v2.0 APIs and exposes a v1.x-esque engine which I'll make available somewhere in a couple of days. ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Michael Foord [fuzzyman at voidspace.org.uk] Sent: Monday, April 30, 2007 4:58 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.0 Alpha 1 Released Hello Dino, Wow - this seems like a big deal. :-) Does IronPython 2 still support hosting multiple IronPython engines ? Thanks Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml Dino Viehland wrote: > > Hello IronPython Community, > > We have just released IronPython 2.0 Alpha 1. IronPython 2.0 will be > the first release of IronPython built upon a common dynamic language > runtime (DLR) as well as targeting version 2.5 of Python. These > release notes list what is new in IronPython 2.0, a brief overview of > the DLR, and what to expect from the 2.0 release. > > > One major focus during this release will be further improving our > conformance with CPython. We?ve already made several improvements, for > example one is that our type system no longer contains a hierarchy of > types: now type(type) is type. We have also fixed a number of issues > related to various statements such as imports and function definitions > inside of exec or eval. There have also been a number of other small > issues fixed that our users reported to us. > > IronPython 2.0 will also be the first major release to support 2.5 out > of the box. In IronPython 1.x, and in this initial alpha release, > users must enable this with a command line switch. During the 2.0 > release cycle we will flush out the remaining 2.5 features and > permanently enable this option. We will also start looking at > supporting v2.6 features via command line switch and start some > experimentation around the 3.0 features. In particular, we are excited > about looking at the new bytes and string types as well as formatting > options that we believe will fit nicely with .NET. > > IronPython 2.0 is also the first release built upon the Dynamic > Language Runtime: a shared runtime for dynamic languages on .NET. The > DLR both reduces the amount of work to create new dynamic languages on > .NET enables rich interoperability between dynamic languages, and > provides a shared module for consuming those languages from > applications. We are particularly excited about the ability to share > code across dynamic languages enabling users to share libraries > without worrying the particular language in which the library is > written. Over time, the DLR will expand and improve bringing language > developers more benefits from this shared infrastructure. We also look > forward to seeing a new era of programmable apps that can support a > wide range of options for end-users. > > When we started working on the DLR we initially used the IronPython > v1.0 code base. From there we extracted the core concepts that were > common to dynamic languages, generalized the concepts that were > specific to Python, expanded the framework to provide rich support for > other dynamic languages, and exposed all of the languages via a common > interface. Starting with IronPython 1.0 was an obvious choice because > it had already captured many of the best practices for building > dynamic languages on .NET and had done a great job leveraging many of > the underlying features of .NET. In IronPython 2.0 all of these best > practices are expanded and implemented with an eye on maximizing > forward compatibility with new features in .NET v3.5 such as LINQ and > extension methods. Moreover, the DLR exposes this functionality to the > language implementer via a small set of core concepts that all dynamic > language implementations can share. > > One additional change in this release is that we?re moving to use the > Microsoft Permissive License for IronPython 2.0. Our original release > of IronPython predated the Microsoft Permissive License, and so we > created a custom license specifically for Iron Python. After releasing > Iron Python, we created new Microsoft Shared Source licenses, > including the Microsoft Permissive License, to facilitate and > standardize source code licensing for appropriate Microsoft projects. > We believe our users appreciate consistency in licensing from > Microsoft. Therefore, because we are now using the more modern > Microsoft Permissive License where appropriate for similar current > source code releases, we feel we should offer IronPython under the > Microsoft Permissive License as well. > > Note because this is an alpha release there is also some missing > functionality that was formerly present in v1.0. This includes CodeDom > support, the static compiler that produced .NET assemblies, support > for creating strongly typed delegates to script code, as well as a > drastically changed hosting API. We will be bringing this > functionality back to future releases in the IronPython 2.0 series as > well many other improvements. > You can download IronPython v2.0 at: 2.0 Alpha > > > If you?d like more details about the DLR, Jim will be using his blog > to post design notes as they are written over the next couple of weeks > ? http://blogs.msdn.com/hugunin. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 info at r-e-d.co.nz Tue May 1 03:16:25 2007 From: info at r-e-d.co.nz (Guy Robinson) Date: Tue, 01 May 2007 13:16:25 +1200 Subject: [IronPython] IronPython 2.0 Alpha 1 Released In-Reply-To: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <463694E9.6030200@r-e-d.co.nz> Curious, How does the DLR affect IP2.0 on mono platforms? Will IP2.0 only run on Windows? Guy Dino Viehland wrote: > Hello IronPython Community, > > post design notes as they are written over the next couple of weeks ? > http://blogs.msdn.com/hugunin. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Tue May 1 04:44:31 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Tue, 1 May 2007 11:44:31 +0900 Subject: [IronPython] IronPython 2.0 Alpha 1 Released In-Reply-To: <463694E9.6030200@r-e-d.co.nz> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <463694E9.6030200@r-e-d.co.nz> Message-ID: <5b0248170704301944j75a0b6aah96826d7a1a4a9f14@mail.gmail.com> 2007/5/1, Guy Robinson : > How does the DLR affect IP2.0 on mono platforms? Will IP2.0 only run on > Windows? I can't compile IP 2.0a1 with Mono 1.2.3.1 at the moment, but I see no reason why it can't be done once relevant compiler bugs are fixed and missing classes and methods implemented. -- Seo Sanghyeon From redmoon17 at gmail.com Tue May 1 06:28:09 2007 From: redmoon17 at gmail.com (Kevin Chu) Date: Tue, 1 May 2007 12:28:09 +0800 Subject: [IronPython] IronPython 2.0 Alpha 1 Released In-Reply-To: <5b0248170704301944j75a0b6aah96826d7a1a4a9f14@mail.gmail.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <463694E9.6030200@r-e-d.co.nz> <5b0248170704301944j75a0b6aah96826d7a1a4a9f14@mail.gmail.com> Message-ID: <41d7f4a90704302128x224b57dfpb8104eb6faf4b50@mail.gmail.com> I want to know IronPython for ASP.NET have any changes? On 5/1/07, Sanghyeon Seo wrote: > > 2007/5/1, Guy Robinson : > > How does the DLR affect IP2.0 on mono platforms? Will IP2.0 only run on > > Windows? > > I can't compile IP 2.0a1 with Mono 1.2.3.1 at the moment, but I see no > reason why it can't be done once relevant compiler bugs are fixed and > missing classes and methods implemented. > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Once in a Redmoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From haiboluo at exchange.microsoft.com Tue May 1 06:43:01 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Mon, 30 Apr 2007 21:43:01 -0700 Subject: [IronPython] IronPython 2.0 Alpha 1 Released In-Reply-To: <41d7f4a90704302128x224b57dfpb8104eb6faf4b50@mail.gmail.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <463694E9.6030200@r-e-d.co.nz> <5b0248170704301944j75a0b6aah96826d7a1a4a9f14@mail.gmail.com>, <41d7f4a90704302128x224b57dfpb8104eb6faf4b50@mail.gmail.com> Message-ID: ASP.NET futures release is shipped today, you can read more about it at http://www.asp.net/downloads/futures/default.aspx?tabid=62. ________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Kevin Chu [redmoon17 at gmail.com] Sent: Monday, April 30, 2007 9:28 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2.0 Alpha 1 Released I want to know IronPython for ASP.NET have any changes? On 5/1/07, Sanghyeon Seo > wrote: 2007/5/1, Guy Robinson >: > How does the DLR affect IP2.0 on mono platforms? Will IP2.0 only run on > Windows? I can't compile IP 2.0a1 with Mono 1.2.3.1 at the moment, but I see no reason why it can't be done once relevant compiler bugs are fixed and missing classes and methods implemented. -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- Once in a Redmoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jim.Hugunin at microsoft.com Tue May 1 06:59:53 2007 From: Jim.Hugunin at microsoft.com (Jim Hugunin) Date: Mon, 30 Apr 2007 21:59:53 -0700 Subject: [IronPython] IronPython 2.0 Alpha 1 Released In-Reply-To: <5b0248170704301944j75a0b6aah96826d7a1a4a9f14@mail.gmail.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <463694E9.6030200@r-e-d.co.nz> <5b0248170704301944j75a0b6aah96826d7a1a4a9f14@mail.gmail.com> Message-ID: Keep in mind that the DLR is shipped with full sources that same way that IronPython itself is on codeplex. It should be able to run the full stack on any fully compliant CLI implementation. In addition to that, with the Silverlight announcements we made today, IronPython is already running on the Microsoft-built .NET runtime in the browser on both Windows and Mac (in an alpha release). All of John's and my talk tomorrow showing IronPython, IronRuby, JavaScript and VB will be run on a Mac Powerbook inside of Safari. I'm having fun tonight getting used to the quirks of the Mac keyboard to make that happen. Thanks - Jim -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Monday, April 30, 2007 7:45 PM To: info at r-e-d.co.nz; Discussion of IronPython Subject: Re: [IronPython] IronPython 2.0 Alpha 1 Released 2007/5/1, Guy Robinson : > How does the DLR affect IP2.0 on mono platforms? Will IP2.0 only run on > Windows? I can't compile IP 2.0a1 with Mono 1.2.3.1 at the moment, but I see no reason why it can't be done once relevant compiler bugs are fixed and missing classes and methods implemented. -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dans at houmus.org Tue May 1 12:03:59 2007 From: dans at houmus.org (Dan Shechter) Date: Tue, 1 May 2007 13:03:59 +0300 Subject: [IronPython] IronPython 2.0 Alpha 1 Released In-Reply-To: References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <463694E9.6030200@r-e-d.co.nz> <5b0248170704301944j75a0b6aah96826d7a1a4a9f14@mail.gmail.com> Message-ID: <2e8aa6310705010303x44e12f17v99c8b3d823bb6fc9@mail.gmail.com> Hi, This might be not the best place to ask this, bu I'm noticing something very strange with SilverLight 1.1alpha and the DLRConsole sample. I can run it from IE7 both from http:// and from file:// I can run it with FireFox 2.0 with http:// When I run it with FireFox 2.0 from file:// I get *Object reference not set to an instance of an object.**Source File: * DLRConsole.py *Exception Details: *System.NullReferenceException: Object reference not set to an instance of an object.. *Stack Trace:* at __name__ in DLRConsole.py, line 24 This happens both on Windows Vista and XP SP2. Line 24 contains the very complex statement: "import wpf"... :) The URL I'm using in FireFox (which DOES work) is: http://silverlight.net/Samples/1.1/DLR-Console/python/index.htm If I use the downloaded sample (either from the silverlight.net gallery, silverlight 1.1 sdk, or the codeplex dynamic silverlight samples site) I get the above excpetion with file://... TIA, Shechter. On 5/1/07, Jim Hugunin wrote: > > Keep in mind that the DLR is shipped with full sources that same way that > IronPython itself is on codeplex. It should be able to run the full stack > on any fully compliant CLI implementation. > > In addition to that, with the Silverlight announcements we made today, > IronPython is already running on the Microsoft-built .NET runtime in the > browser on both Windows and Mac (in an alpha release). All of John's and my > talk tomorrow showing IronPython, IronRuby, JavaScript and VB will be run on > a Mac Powerbook inside of Safari. I'm having fun tonight getting used to > the quirks of the Mac keyboard to make that happen. > > Thanks - Jim > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo > Sent: Monday, April 30, 2007 7:45 PM > To: info at r-e-d.co.nz; Discussion of IronPython > Subject: Re: [IronPython] IronPython 2.0 Alpha 1 Released > > 2007/5/1, Guy Robinson : > > How does the DLR affect IP2.0 on mono platforms? Will IP2.0 only run on > > Windows? > > I can't compile IP 2.0a1 with Mono 1.2.3.1 at the moment, but I see no > reason why it can't be done once relevant compiler bugs are fixed and > missing classes and methods implemented. > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Shechter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From redmoon17 at gmail.com Tue May 1 18:33:31 2007 From: redmoon17 at gmail.com (Kevin Chu) Date: Wed, 2 May 2007 00:33:31 +0800 Subject: [IronPython] bug in IronPython 2.0 with SilverLight in Firefox Message-ID: <41d7f4a90705010933p6b3a06eay66908315976de542@mail.gmail.com> I run Dynamic SilverLight sample "wordfind" in Firefox ,I get a error: ================== *Object reference not set to an instance of an object.* *Source File: * wordfind.py *Exception Details: *System.NullReferenceException: Object reference not set to an instance of an object.. *Stack Trace:* at __name__ in wordfind.py, line 4 ================= but I run this sample in IE7 ,it's ok! -- Once in a Redmoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From haiboluo at exchange.microsoft.com Tue May 1 18:39:20 2007 From: haiboluo at exchange.microsoft.com (Haibo Luo) Date: Tue, 1 May 2007 09:39:20 -0700 Subject: [IronPython] bug in IronPython 2.0 with SilverLight in Firefox In-Reply-To: <41d7f4a90705010933p6b3a06eay66908315976de542@mail.gmail.com> References: <41d7f4a90705010933p6b3a06eay66908315976de542@mail.gmail.com> Message-ID: Thanks for reporting this. This is known issue. In order to import a module (in Firefox), the app has to be running via http:// . The workaround when you write your own app, is to put all code in one py file for now, so it would work in both file:// and http:// (also both IE and FF). From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kevin Chu Sent: Tuesday, May 01, 2007 9:34 AM To: Discussion of IronPython Subject: [IronPython] bug in IronPython 2.0 with SilverLight in Firefox I run Dynamic SilverLight sample "wordfind" in Firefox ,I get a error: ================== Object reference not set to an instance of an object. Source File: wordfind.py Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.. Stack Trace: at __name__ in wordfind.py, line 4 ================= but I run this sample in IE7 ,it's ok! -- Once in a Redmoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at v-sim.com Tue May 1 23:45:44 2007 From: tony at v-sim.com (Tony Djordjevski) Date: Tue, 01 May 2007 17:45:44 -0400 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <4637B508.4070001@v-sim.com> Hi Dino, You indicated that multiple engine support might be available in the coming changes with the hosting APIs. Is there any chance that we can get a definitive answer one way or another? And if so, will it be available for 2.0 final? Our product depends on IronPython being able to run multiple scripts in isolation from each other. At some point in the future, we'd also like to be able to run scripts in parallel. Now, I don't know if there is another mechanism planned (or currently available) that would allow us to do this, but I believe multiple engine instances would give us these capabilities. Thanks for the consideration, Tony Dino Viehland wrote: > Yeah, incase the release notes aren't obvious there's a bunch of things that go with this: IronPython in the web browser (IE, FireFox, and Safari - yes, there's Mac support as well) via Silverlight. There's an ASP.NET Futures which has also launched (linked from our home page on CodePlex), not to mention the DLR. > > Anyway, back to the hosting APIs :). They don't support multiple instances now but we still have an additional round of changes to go through w/ the hosting APIs. I'm not sure what will happen with that. I'm also not sure that we actively prevent creating 2 instances but I know we've made some spots singleton's that used to not be - therefore if you tried it you'd likely run into issues. Additionally the entire hosting API surface is also quite different. I have a version that wraps the v2.0 APIs and exposes a v1.x-esque engine which I'll make available somewhere in a couple of days. > > ________________________________________ > From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Michael Foord [fuzzyman at voidspace.org.uk] > Sent: Monday, April 30, 2007 4:58 PM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython 2.0 Alpha 1 Released > > Hello Dino, > > Wow - this seems like a big deal. :-) > > Does IronPython 2 still support hosting multiple IronPython engines ? > > Thanks > > Michael Foord > http://www.voidspace.org.uk/ironpython/index.shtml > From dinov at exchange.microsoft.com Wed May 2 02:36:15 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 1 May 2007 17:36:15 -0700 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <4637B508.4070001@v-sim.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> Message-ID: <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I'm not actually the one working on the engine APIs so that's the reason I've tended to be vague. I'll talk to the people doing it and let you know what I hear. But the more info you can give us the better decision we'll be able to make. For example what do you actually need to be isolated? Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? Ultimately understanding the scenarios where this is being used might end up with us coming up with an even better solution. The reasons why I ask that is because there are already many options on isolation depending upon what you're trying to do. For example in the dynamic language support for ASP.NET we're executing the same code in multiple modules. That gives each thread it's own set of globals but could allow sharing through system state. It also means that the different requests get to share imported modules. That's not much isolation but it could be enough for a lot of scenarios. On the other extreme is full app domain isolation. The more info we get here the more likely we'll capture the right result. The real challenge here is it's actually impossible for us to offer full isolation w/o going to app domain isolation. So anything we create will be less; for example Michael Foord noted that the recursion enforcement is a global setting and it's hard to not make that global. So we just need to figure out the right "less" that is both useful, maintainable, and understandable. ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski [tony at v-sim.com] Sent: Tuesday, May 01, 2007 2:45 PM To: Discussion of IronPython Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Hi Dino, You indicated that multiple engine support might be available in the coming changes with the hosting APIs. Is there any chance that we can get a definitive answer one way or another? And if so, will it be available for 2.0 final? Our product depends on IronPython being able to run multiple scripts in isolation from each other. At some point in the future, we'd also like to be able to run scripts in parallel. Now, I don't know if there is another mechanism planned (or currently available) that would allow us to do this, but I believe multiple engine instances would give us these capabilities. Thanks for the consideration, Tony Dino Viehland wrote: > Yeah, incase the release notes aren't obvious there's a bunch of things that go with this: IronPython in the web browser (IE, FireFox, and Safari - yes, there's Mac support as well) via Silverlight. There's an ASP.NET Futures which has also launched (linked from our home page on CodePlex), not to mention the DLR. > > Anyway, back to the hosting APIs :). They don't support multiple instances now but we still have an additional round of changes to go through w/ the hosting APIs. I'm not sure what will happen with that. I'm also not sure that we actively prevent creating 2 instances but I know we've made some spots singleton's that used to not be - therefore if you tried it you'd likely run into issues. Additionally the entire hosting API surface is also quite different. I have a version that wraps the v2.0 APIs and exposes a v1.x-esque engine which I'll make available somewhere in a couple of days. > > ________________________________________ > From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Michael Foord [fuzzyman at voidspace.org.uk] > Sent: Monday, April 30, 2007 4:58 PM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython 2.0 Alpha 1 Released > > Hello Dino, > > Wow - this seems like a big deal. :-) > > Does IronPython 2 still support hosting multiple IronPython engines ? > > Thanks > > Michael Foord > http://www.voidspace.org.uk/ironpython/index.shtml > _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From jeffrey at extremeoptimization.com Wed May 2 03:06:20 2007 From: jeffrey at extremeoptimization.com (Jeffrey Sax) Date: Tue, 1 May 2007 21:06:20 -0400 Subject: [IronPython] DLR and VS-Interactive In-Reply-To: <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk><7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <005801c78c56$1bf2edd0$6400a8c0@numericedge01> This is more a DLR than an IronPython question. There are two 'dynamic' aspects that are covered by the DLR extension to the CLR. One is runtime support for efficient dynamic typing. The other is the hosting side: console interface, integration with Visual Studio, etc. These are useful for other (non-dynamic) languages as well. Case in point: F# has an interactive console in Visual Studio, but is compiled and statically typed. This second aspect looks more like an extension of the Visual Studio SDK, if it wasn't taken straight from the VS Integration samples from the VS SDK. In other words: my impression is that the current DLR is made up of two separable parts: 1. The actual DLR, which enables efficient dynamic typing on the CLR. 2. "VS-Interactive", a set of extensions to the Visual Studio SDK that turn Visual Studio into an interactive development environment. Is this where the refactoring is headed? Jeffrey Sax Extreme Optimization From kfarmer at thuban.org Wed May 2 03:37:56 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 1 May 2007 18:37:56 -0700 Subject: [IronPython] DLR and VS-Interactive Message-ID: Not really an answer, but more of a related topic: have you tried out the Silverlight 1.1 alpha (not the go-live beta), and then the DLRConsole sample? One dynamic aspect seen there which you don't mention is dynamism in the language-of-the-moment: you can switch from Python to JScript mid-session and still operate in the same context. ________________________________ From: users-bounces at lists.ironpython.com on behalf of Jeffrey Sax Sent: Tue 5/1/2007 6:06 PM To: 'Discussion of IronPython' Subject: [IronPython] DLR and VS-Interactive This is more a DLR than an IronPython question. There are two 'dynamic' aspects that are covered by the DLR extension to the CLR. One is runtime support for efficient dynamic typing. The other is the hosting side: console interface, integration with Visual Studio, etc. These are useful for other (non-dynamic) languages as well. Case in point: F# has an interactive console in Visual Studio, but is compiled and statically typed. This second aspect looks more like an extension of the Visual Studio SDK, if it wasn't taken straight from the VS Integration samples from the VS SDK. In other words: my impression is that the current DLR is made up of two separable parts: 1. The actual DLR, which enables efficient dynamic typing on the CLR. 2. "VS-Interactive", a set of extensions to the Visual Studio SDK that turn Visual Studio into an interactive development environment. Is this where the refactoring is headed? Jeffrey Sax Extreme Optimization _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Wed May 2 11:16:32 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 2 May 2007 18:16:32 +0900 Subject: [IronPython] Missing reference in makefile Message-ID: <5b0248170705020216m401a3bb9v1327d838ca572557@mail.gmail.com> In IronPython 2.0 Alpha 1 makefile, I think build instruction for Microsoft.Scripting.dll is missing reference to System.Configuration.dll. Am I correct? -- Seo Sanghyeon From sanxiyn at gmail.com Wed May 2 12:22:00 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 2 May 2007 19:22:00 +0900 Subject: [IronPython] IronPython 2.0 Alpha 1 on Mono Message-ID: <5b0248170705020322x4663ac42t997a2f63f1d363be@mail.gmail.com> Here's my first try on building IronPython 2.0 Alpha 1 on Mono: https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/2.0a1/ First, get Mono from SVN, revision later than 76552. Because of an oversight, Mono's C# compiler (actually parser) didn't allow attributes in parameters of operator methods. Namely: "public static object operator >([NotNull]OldInstance self, object other)" was rejected. This is now fixed. 1. patch-makefile Spaces to tabs. Backward slashes to forward slashes. csc to gmcs. Also, add missing System.Configuration.dll reference. 2. patch-81500 Mono's C# compiler currently doesn't compile the expressions of the form 'obj as string ?? ""', where "as" operator associates more strongly than "??" operator. This is Mono bug #81500. http://bugzilla.ximian.com/show_bug.cgi?id=81500 patch-81500 workarounds this bug by parenthesizing all such expressions in the IronPython 2.0 Alpha 1 source code. 3. patch-delegate-conversion Mono's C# compiler currently doesn't handle implicit standard delegate conversion from DefaultNameTransform to ExtensionNameTransformer in ReflectedTypeBuilder.cs. My workaround is to explicitly declare the delegate and assign later. After these, gmcs crashes inside Mono runtime with backtrace pointing to custom attribute resolution. Still investigating, but above three patches should help anyone trying to dig this on their own together with me. :) Good luck! -- Seo Sanghyeon From fuzzyman at voidspace.org.uk Wed May 2 14:50:54 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 02 May 2007 13:50:54 +0100 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <4638892E.3060300@voidspace.org.uk> Dino Viehland wrote: > I'm not actually the one working on the engine APIs so that's the reason I've tended to be vague. I'll talk to the people doing it and let you know what I hear. > > But the more info you can give us the better decision we'll be able to make. For example what do you actually need to be isolated? Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? > At Resolver we are currently using multiple IronPython engines. Moving to AppDomains is a long term goal for us, but is actually quite a lot of work (we would have *lots* of cross-domain calls and so to avoid that we have to find an efficient way of pumping lots of data in and then out of the app domain). Switching to app domains is not a high priority task for us, and in the meantime we *can't* upgrade to IronPython 2 if it doesn't support multiple engines. Isolation of engines is only a minor benefit (it is a positive side effect - but not the reason we started using them) for us at the moment, and an isolated system state (although nice) is not vital. All the best, Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml From fuzzyman at voidspace.org.uk Wed May 2 14:57:38 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 02 May 2007 13:57:38 +0100 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <4638892E.3060300@voidspace.org.uk> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638892E.3060300@voidspace.org.uk> Message-ID: <46388AC2.7080301@voidspace.org.uk> Michael Foord wrote: > Dino Viehland wrote: > >> I'm not actually the one working on the engine APIs so that's the reason I've tended to be vague. I'll talk to the people doing it and let you know what I hear. >> >> But the more info you can give us the better decision we'll be able to make. For example what do you actually need to be isolated? Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? >> >> > At Resolver we are currently using multiple IronPython engines. Moving > to AppDomains is a long term goal for us, but is actually quite a lot of > work (we would have *lots* of cross-domain calls and so to avoid that we > have to find an efficient way of pumping lots of data in and then out of > the app domain). > > Switching to app domains is not a high priority task for us, and in the > meantime we *can't* upgrade to IronPython 2 if it doesn't support > multiple engines. > > Isolation of engines is only a minor benefit (it is a positive side > effect - but not the reason we started using them) for us at the moment, > and an isolated system state (although nice) is not vital. > > In fact, the reason we started using multiple engines was to divert the standard output of simultaneously running user scripts to different output windows... Michael > All the best, > > Michael Foord > http://www.voidspace.org.uk/ironpython/index.shtml > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From michael.foord at resolversystems.com Wed May 2 15:44:46 2007 From: michael.foord at resolversystems.com (Michael Foord) Date: Wed, 02 May 2007 14:44:46 +0100 Subject: [IronPython] Silverlight SDK Demos Message-ID: <463895CE.9090607@resolversystems.com> Hello all, I've been playing around with Silverlight 1.1 and the samples that come with the SDK. The two samples I could get working were very impressive - the DLR console and the image viewer. None of the others seemed to work out of the box. (Install Silverlight 1.1 Alpha, drop a simple http server into the samples directory - navigate to the appropriate Default.html or index.html page.) In addition to this, a lot of the samples have javascript files named 'default.html.js' or similar. This triggers the AVG anti-virus 'hidden extesnion' warning which is most annoying. To add insult to injury, the documentation seems to come as an ASP site. Yeeurgh! :-) Some fun looking samples on the 'dynamicsilverlight' codeplex page though. Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml -- Michael Foord Resolver Systems michael.foord at resolversystems.com Office address: 17a Clerkenwell Road, London EC1M 5RD, UK Registered address: 843 Finchley Road, London NW11 8NA, UK Resolver Systems Limited is registered in England and Wales as company number 5467329. VAT No. GB 893 5643 79 From dinov at exchange.microsoft.com Wed May 2 17:58:33 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 2 May 2007 08:58:33 -0700 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <46388AC2.7080301@voidspace.org.uk> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638892E.3060300@voidspace.org.uk> <46388AC2.7080301@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222790ACCE2CA0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> The scripts are running on multiple threads? The easy way to do this in v2.0 is to set console output (we no longer maintain our own output streams) to be a stream which looks at a thread static variable which is the real stream to output to. Would that solve the entire isolation problem for you? The only problem w/ this is if user code sets sys.stdout they'll hijack all the other scripts. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Wednesday, May 02, 2007 5:58 AM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Michael Foord wrote: > Dino Viehland wrote: > >> I'm not actually the one working on the engine APIs so that's the reason I've tended to be vague. I'll talk to the people doing it and let you know what I hear. >> >> But the more info you can give us the better decision we'll be able to make. For example what do you actually need to be isolated? Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? >> >> > At Resolver we are currently using multiple IronPython engines. Moving > to AppDomains is a long term goal for us, but is actually quite a lot of > work (we would have *lots* of cross-domain calls and so to avoid that we > have to find an efficient way of pumping lots of data in and then out of > the app domain). > > Switching to app domains is not a high priority task for us, and in the > meantime we *can't* upgrade to IronPython 2 if it doesn't support > multiple engines. > > Isolation of engines is only a minor benefit (it is a positive side > effect - but not the reason we started using them) for us at the moment, > and an isolated system state (although nice) is not vital. > > In fact, the reason we started using multiple engines was to divert the standard output of simultaneously running user scripts to different output windows... Michael > All the best, > > Michael Foord > http://www.voidspace.org.uk/ironpython/index.shtml > > _______________________________________________ > 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 May 2 18:04:42 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 2 May 2007 09:04:42 -0700 Subject: [IronPython] Missing reference in makefile In-Reply-To: <5b0248170705020216m401a3bb9v1327d838ca572557@mail.gmail.com> References: <5b0248170705020216m401a3bb9v1327d838ca572557@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222790ACCE2CA5@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I think you're right - we probably can get away w/ it using csc because it has a large list of references it'll eagerly add and if you happen to use them. I'll fix 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: Wednesday, May 02, 2007 2:17 AM To: Discussion of IronPython Subject: [IronPython] Missing reference in makefile In IronPython 2.0 Alpha 1 makefile, I think build instruction for Microsoft.Scripting.dll is missing reference to System.Configuration.dll. Am I correct? -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Wed May 2 18:05:59 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 02 May 2007 17:05:59 +0100 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <7AD436E4270DD54A94238001769C222790ACCE2CA0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638892E.3060300@voidspace.org.uk> <46388AC2.7080301@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACCE2CA0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <4638B6E7.6000803@voidspace.org.uk> My guess is that you have to use outlook. It does seem to encourage top-posting. ;-) Dino Viehland wrote: > The scripts are running on multiple threads? Usually - although sometimes code is executed on the GUI thread, but in this case we always know where to send the output. > The easy way to do this in v2.0 is to set console output (we no longer maintain our own output streams) to be a stream which looks at a thread static variable which is the real stream to output to. Would that solve the entire isolation problem for you? > Our current code is nice and elegant, whilst yours sounds hacky. :-p Actually its just a solution we didn't think of, although it isn't quite as nice as running them in separate engines which we do now, and does give us *some* measure of isolation. (It is slightly less likely that a badly written user script will now kill the whole application, although obviously still very easy.) > The only problem w/ this is if user code sets sys.stdout they'll hijack all the other scripts. > Which is a problem - but we can always say "don't do that then"... I think we still like our current use of multiple engines, and would prefer to see that supported in IronPython 2.0, even with a shared SystemState. At least you have given us an alternative without *having* to use AppDomains if this isn't possible. Thanks Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Wednesday, May 02, 2007 5:58 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) > > Michael Foord wrote: > >> Dino Viehland wrote: >> >> >>> I'm not actually the one working on the engine APIs so that's the reason I've tended to be vague. I'll talk to the people doing it and let you know what I hear. >>> >>> But the more info you can give us the better decision we'll be able to make. For example what do you actually need to be isolated? Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? >>> >>> >>> >> At Resolver we are currently using multiple IronPython engines. Moving >> to AppDomains is a long term goal for us, but is actually quite a lot of >> work (we would have *lots* of cross-domain calls and so to avoid that we >> have to find an efficient way of pumping lots of data in and then out of >> the app domain). >> >> Switching to app domains is not a high priority task for us, and in the >> meantime we *can't* upgrade to IronPython 2 if it doesn't support >> multiple engines. >> >> Isolation of engines is only a minor benefit (it is a positive side >> effect - but not the reason we started using them) for us at the moment, >> and an isolated system state (although nice) is not vital. >> >> >> > > In fact, the reason we started using multiple engines was to divert the > standard output of simultaneously running user scripts to different > output windows... > > Michael > > > >> All the best, >> >> Michael Foord >> http://www.voidspace.org.uk/ironpython/index.shtml >> >> _______________________________________________ >> 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 tony at v-sim.com Wed May 2 18:59:24 2007 From: tony at v-sim.com (Tony Djordjevski) Date: Wed, 02 May 2007 12:59:24 -0400 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <4638C36C.8090702@v-sim.com> Thanks for the reply Dino. And sorry, this is going to be a long post. I guess the best way to tell you what we need from IronPython is to tell you how our product works today. I should also note that we're porting the application from native C++ to .Net. We currently have python support by way of CPython and the Boost Python library. Our product is an emulation/simulation application within the manufacturing domain. Our customers are able to emulate their manufacturing process by adding virtual machines (what we call components) to a 3D world that represents their factory floor. Each component can have various "behaviors", and we supply some common behaviors which the customer can add to a component. For example, a conveyor component would have behaviors that deal with conveyance, sensors that detect parts moving along the conveyor, and signals used for communication, among others. The scripts are important because they are a means for the customer to create custom behaviors (you can almost think of them as plugins). Using the above example of a conveyor, a part might move down the conveyor, a sensor would detect that part and then fire a signal. That signal could be "wired" up to a script behavior. The script in turn might turn off the conveyor, or slow it down, or do throughput analysis, or a number of other things. The customer might have a number of these same conveyors on the factory floor all with the same script behavior(s). The scripts need to be isolated insofar that when they do turn off the conveyor, as in the example above, that they turn off the conveyor in the component they are associated with. So I would have to say that the state of the script "instance" needs to be separate from each other. The scripts don't run all the time. They run once during compilation, as that's the behavior of CPython. So any statements at the main module level get executed then. If the script has specific functions defined, we call those python functions when particular simulation events take place. To answer some of your specific questions: Q1. Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? A1. I would have to say yes, for the most part. Shallow copies of imported modules are probably OK, but we aren't far enough into the migration to give you a definitive answer. There is one case in our C++ implementation that this caused a problem and we were forced to call the module's init function for each interpreter behind the scenes. As far as everything in sys is concerned, maybe not but I can think of at least one situation that it must be isolated. Currently, we redirect sys.stdout and sys.stderr to a window in our application, but that doesn't stop a user from redefining those manually in one of their scripts. If they do, then it shouldn't affect any other script in the application. Other things, like sys.version, don't have to be isolated. Q2. Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). A2. No and in our case I don't think that would be desirable. The scripts themselves need to be able to interact with other objects within the simulation world. Q3. If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? A4. I'm fairly new to .Net, so I'm not sure. I'll have to read up on app domains, but my gut tells me that is not what we want here. I hope this sheds more light, Dino. I tried to be as clear as possible, but it was a bit difficult to keep this short(ish) and still convey our needs. Let me know if I can elaborate on any other questions you might have, or if anything I've wrote here is unclear. One thing to think about: eventually we want to make our simulation engine multi-threaded. Script functions will probably be getting executed in parallel at some point. Thanks, Tony Dino Viehland wrote: > I'm not actually the one working on the engine APIs so that's the reason I've tended to be vague. I'll talk to the people doing it and let you know what I hear. > > But the more info you can give us the better decision we'll be able to make. For example what do you actually need to be isolated? Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? > > Ultimately understanding the scenarios where this is being used might end up with us coming up with an even better solution. > > The reasons why I ask that is because there are already many options on isolation depending upon what you're trying to do. For example in the dynamic language support for ASP.NET we're executing the same code in multiple modules. That gives each thread it's own set of globals but could allow sharing through system state. It also means that the different requests get to share imported modules. That's not much isolation but it could be enough for a lot of scenarios. On the other extreme is full app domain isolation. > > The more info we get here the more likely we'll capture the right result. The real challenge here is it's actually impossible for us to offer full isolation w/o going to app domain isolation. So anything we create will be less; for example Michael Foord noted that the recursion enforcement is a global setting and it's hard to not make that global. So we just need to figure out the right "less" that is both useful, maintainable, and understandable. > From dinov at exchange.microsoft.com Wed May 2 19:16:42 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 2 May 2007 10:16:42 -0700 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <4638C36C.8090702@v-sim.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638C36C.8090702@v-sim.com> Message-ID: <7AD436E4270DD54A94238001769C222790ACCE2D07@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Thanks for the info... Darn, it sounds like you actually want sys to be isolated... We're going to do a review over the hosting APIs internally next week. That should result in the last large set of changes. One thought that has occurred to me is the ability to provide management of the current sys instance. This is where most of the state is tracked. That would presumably be something like allowing you to create a new system state and provide the current system state at runtime. You could then switch system states before running a new script code. In the multi-threaded case you could store the system state in a thread local variable. Therefore rather than tracking a set of engines you'd track a list of SystemState objects (or in DLR speak they may be some opaque state object). The one interesting thing here is how this plays w/ console output. In v2.0 that's separate from SystemState so you'd also need to update those at the same time. Any feedback on that proposal? -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski Sent: Wednesday, May 02, 2007 9:59 AM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Thanks for the reply Dino. And sorry, this is going to be a long post. I guess the best way to tell you what we need from IronPython is to tell you how our product works today. I should also note that we're porting the application from native C++ to .Net. We currently have python support by way of CPython and the Boost Python library. Our product is an emulation/simulation application within the manufacturing domain. Our customers are able to emulate their manufacturing process by adding virtual machines (what we call components) to a 3D world that represents their factory floor. Each component can have various "behaviors", and we supply some common behaviors which the customer can add to a component. For example, a conveyor component would have behaviors that deal with conveyance, sensors that detect parts moving along the conveyor, and signals used for communication, among others. The scripts are important because they are a means for the customer to create custom behaviors (you can almost think of them as plugins). Using the above example of a conveyor, a part might move down the conveyor, a sensor would detect that part and then fire a signal. That signal could be "wired" up to a script behavior. The script in turn might turn off the conveyor, or slow it down, or do throughput analysis, or a number of other things. The customer might have a number of these same conveyors on the factory floor all with the same script behavior(s). The scripts need to be isolated insofar that when they do turn off the conveyor, as in the example above, that they turn off the conveyor in the component they are associated with. So I would have to say that the state of the script "instance" needs to be separate from each other. The scripts don't run all the time. They run once during compilation, as that's the behavior of CPython. So any statements at the main module level get executed then. If the script has specific functions defined, we call those python functions when particular simulation events take place. To answer some of your specific questions: Q1. Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? A1. I would have to say yes, for the most part. Shallow copies of imported modules are probably OK, but we aren't far enough into the migration to give you a definitive answer. There is one case in our C++ implementation that this caused a problem and we were forced to call the module's init function for each interpreter behind the scenes. As far as everything in sys is concerned, maybe not but I can think of at least one situation that it must be isolated. Currently, we redirect sys.stdout and sys.stderr to a window in our application, but that doesn't stop a user from redefining those manually in one of their scripts. If they do, then it shouldn't affect any other script in the application. Other things, like sys.version, don't have to be isolated. Q2. Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). A2. No and in our case I don't think that would be desirable. The scripts themselves need to be able to interact with other objects within the simulation world. Q3. If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? A4. I'm fairly new to .Net, so I'm not sure. I'll have to read up on app domains, but my gut tells me that is not what we want here. I hope this sheds more light, Dino. I tried to be as clear as possible, but it was a bit difficult to keep this short(ish) and still convey our needs. Let me know if I can elaborate on any other questions you might have, or if anything I've wrote here is unclear. One thing to think about: eventually we want to make our simulation engine multi-threaded. Script functions will probably be getting executed in parallel at some point. Thanks, Tony Dino Viehland wrote: > I'm not actually the one working on the engine APIs so that's the reason I've tended to be vague. I'll talk to the people doing it and let you know what I hear. > > But the more info you can give us the better decision we'll be able to make. For example what do you actually need to be isolated? Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? > > Ultimately understanding the scenarios where this is being used might end up with us coming up with an even better solution. > > The reasons why I ask that is because there are already many options on isolation depending upon what you're trying to do. For example in the dynamic language support for ASP.NET we're executing the same code in multiple modules. That gives each thread it's own set of globals but could allow sharing through system state. It also means that the different requests get to share imported modules. That's not much isolation but it could be enough for a lot of scenarios. On the other extreme is full app domain isolation. > > The more info we get here the more likely we'll capture the right result. The real challenge here is it's actually impossible for us to offer full isolation w/o going to app domain isolation. So anything we create will be less; for example Michael Foord noted that the recursion enforcement is a global setting and it's hard to not make that global. So we just need to figure out the right "less" that is both useful, maintainable, and understandable. > _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From kristof.wagemans at gmail.com Wed May 2 19:46:34 2007 From: kristof.wagemans at gmail.com (Kristof Wagemans) Date: Wed, 2 May 2007 19:46:34 +0200 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <7AD436E4270DD54A94238001769C222790ACCE2D07@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk><7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com><7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com><4638C36C.8090702@v-sim.com> <7AD436E4270DD54A94238001769C222790ACCE2D07@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <000b01c78ce1$d3e096f0$6401a8c0@notebook> Is the following scenario supported in v2.0? You have a Windows MDI application with two child windows open. Each window contains a textbox and a label. No extra threads. No extra app domains. You enter a command in the textbox on child window 1 and send it to the engine for execution. The output of the command is displayed in the label on window 1. Then you do the same thing for child window 2. Is the output of the second command displayed in the label on window 2? -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday 2 May 2007 19:17 To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Thanks for the info... Darn, it sounds like you actually want sys to be isolated... We're going to do a review over the hosting APIs internally next week. That should result in the last large set of changes. One thought that has occurred to me is the ability to provide management of the current sys instance. This is where most of the state is tracked. That would presumably be something like allowing you to create a new system state and provide the current system state at runtime. You could then switch system states before running a new script code. In the multi-threaded case you could store the system state in a thread local variable. Therefore rather than tracking a set of engines you'd track a list of SystemState objects (or in DLR speak they may be some opaque state object). The one interesting thing here is how this plays w/ console output. In v2.0 that's separate from SystemState so you'd also need to update those at the same time. Any feedback on that proposal? From dinov at exchange.microsoft.com Wed May 2 19:51:04 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 2 May 2007 10:51:04 -0700 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <000b01c78ce1$d3e096f0$6401a8c0@notebook> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk><7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com><7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com><4638C36C.8090702@v-sim.com> <7AD436E4270DD54A94238001769C222790ACCE2D07@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <000b01c78ce1$d3e096f0$6401a8c0@notebook> Message-ID: <7AD436E4270DD54A94238001769C222790ACCE2D46@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Well the good news is redirecting stdout seems to be the most common scenario :) In v2.0 by default all output is done via the current stream on Console. You could change this stream in the handler which is sending the command to the engine before executing each request. Each window would send the request to the same engine but output to a different stream. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kristof Wagemans Sent: Wednesday, May 02, 2007 10:47 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Is the following scenario supported in v2.0? You have a Windows MDI application with two child windows open. Each window contains a textbox and a label. No extra threads. No extra app domains. You enter a command in the textbox on child window 1 and send it to the engine for execution. The output of the command is displayed in the label on window 1. Then you do the same thing for child window 2. Is the output of the second command displayed in the label on window 2? -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday 2 May 2007 19:17 To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Thanks for the info... Darn, it sounds like you actually want sys to be isolated... We're going to do a review over the hosting APIs internally next week. That should result in the last large set of changes. One thought that has occurred to me is the ability to provide management of the current sys instance. This is where most of the state is tracked. That would presumably be something like allowing you to create a new system state and provide the current system state at runtime. You could then switch system states before running a new script code. In the multi-threaded case you could store the system state in a thread local variable. Therefore rather than tracking a set of engines you'd track a list of SystemState objects (or in DLR speak they may be some opaque state object). The one interesting thing here is how this plays w/ console output. In v2.0 that's separate from SystemState so you'd also need to update those at the same time. Any feedback on that proposal? _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Wed May 2 19:52:53 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 2 May 2007 10:52:53 -0700 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <4638B6E7.6000803@voidspace.org.uk> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638892E.3060300@voidspace.org.uk> <46388AC2.7080301@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACCE2CA0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638B6E7.6000803@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222790ACCE2D49@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I didn't even realize posting at the top was considered a no-no on mailing list etiquette... But indeed, I am using Outlook. I wonder if there's an option to change that somewhere... Thanks for your feedback Michael. This thread has diverged a little bit so let me know if you have any thoughts on the rest of it. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Wednesday, May 02, 2007 9:06 AM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) My guess is that you have to use outlook. It does seem to encourage top-posting. ;-) Dino Viehland wrote: > The scripts are running on multiple threads? Usually - although sometimes code is executed on the GUI thread, but in this case we always know where to send the output. > The easy way to do this in v2.0 is to set console output (we no longer maintain our own output streams) to be a stream which looks at a thread static variable which is the real stream to output to. Would that solve the entire isolation problem for you? > Our current code is nice and elegant, whilst yours sounds hacky. :-p Actually its just a solution we didn't think of, although it isn't quite as nice as running them in separate engines which we do now, and does give us *some* measure of isolation. (It is slightly less likely that a badly written user script will now kill the whole application, although obviously still very easy.) > The only problem w/ this is if user code sets sys.stdout they'll hijack all the other scripts. > Which is a problem - but we can always say "don't do that then"... I think we still like our current use of multiple engines, and would prefer to see that supported in IronPython 2.0, even with a shared SystemState. At least you have given us an alternative without *having* to use AppDomains if this isn't possible. Thanks Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Wednesday, May 02, 2007 5:58 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) > > Michael Foord wrote: > >> Dino Viehland wrote: >> >> >>> I'm not actually the one working on the engine APIs so that's the reason I've tended to be vague. I'll talk to the people doing it and let you know what I hear. >>> >>> But the more info you can give us the better decision we'll be able to make. For example what do you actually need to be isolated? Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? >>> >>> >>> >> At Resolver we are currently using multiple IronPython engines. Moving >> to AppDomains is a long term goal for us, but is actually quite a lot of >> work (we would have *lots* of cross-domain calls and so to avoid that we >> have to find an efficient way of pumping lots of data in and then out of >> the app domain). >> >> Switching to app domains is not a high priority task for us, and in the >> meantime we *can't* upgrade to IronPython 2 if it doesn't support >> multiple engines. >> >> Isolation of engines is only a minor benefit (it is a positive side >> effect - but not the reason we started using them) for us at the moment, >> and an isolated system state (although nice) is not vital. >> >> >> > > In fact, the reason we started using multiple engines was to divert the > standard output of simultaneously running user scripts to different > output windows... > > Michael > > > >> All the best, >> >> Michael Foord >> http://www.voidspace.org.uk/ironpython/index.shtml >> >> _______________________________________________ >> 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 tony at v-sim.com Wed May 2 21:02:14 2007 From: tony at v-sim.com (Tony Djordjevski) Date: Wed, 02 May 2007 15:02:14 -0400 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <7AD436E4270DD54A94238001769C222790ACCE2D07@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638C36C.8090702@v-sim.com> <7AD436E4270DD54A94238001769C222790ACCE2D07@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <4638E036.3030404@v-sim.com> Dino Viehland wrote: > Thanks for the info... Darn, it sounds like you actually want sys to be isolated... > > We're going to do a review over the hosting APIs internally next week. That should result in the last large set of changes. One thought that has occurred to me is the ability to provide management of the current sys instance. This is where most of the state is tracked. That would presumably be something like allowing you to create a new system state and provide the current system state at runtime. You could then switch system states before running a new script code. In the multi-threaded case you could store the system state in a thread local variable. Therefore rather than tracking a set of engines you'd track a list of SystemState objects (or in DLR speak they may be some opaque state object). It sounds very similar to what we are currently doing with the native implementation. We are swapping out PyThreadState pointers by means of PyEval_AcquireThread and PyEval_ReleaseThread (See the Python/C API Reference, if you're interested). There is one problem that we've encountered by doing this: that is when there is some external stimuli (for lack of a better word) on a particular script while the state is swapped out. Python code tries to get executed when it's not available and the system crashes. The two most common cases our customers have been wanting to do (and we really want to give them this capability) is to create GUI for their scripts and to do sockets. In the case of the GUI, if a user clicks a button and the script has been swapped out, then there's trouble. Same with sockets when you receive a transmission. Both of these cases work fine if there is exactly one script in the whole system, but as soon as you add another, it's no dice. I guess the question is how do you swap a state back in when someone else is initiating the switch? Now, it could just be that this won't be a problem with what you're proposing, but I'll need more information. > The one interesting thing here is how this plays w/ console output. In v2.0 that's separate from SystemState so you'd also need to update those at the same time. That's not a problem, as we're already doing this in the native implementation. > Any feedback on that proposal? > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Tony Djordjevski > Sent: Wednesday, May 02, 2007 9:59 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) > > Thanks for the reply Dino. And sorry, this is going to be a long post. > > I guess the best way to tell you what we need from IronPython is to tell > you how our product works today. I should also note that we're porting > the application from native C++ to .Net. We currently have python > support by way of CPython and the Boost Python library. > > Our product is an emulation/simulation application within the > manufacturing domain. Our customers are able to emulate their > manufacturing process by adding virtual machines (what we call > components) to a 3D world that represents their factory floor. Each > component can have various "behaviors", and we supply some common > behaviors which the customer can add to a component. For example, a > conveyor component would have behaviors that deal with conveyance, > sensors that detect parts moving along the conveyor, and signals used > for communication, among others. > > The scripts are important because they are a means for the customer to > create custom behaviors (you can almost think of them as plugins). > Using the above example of a conveyor, a part might move down the > conveyor, a sensor would detect that part and then fire a signal. That > signal could be "wired" up to a script behavior. The script in turn > might turn off the conveyor, or slow it down, or do throughput analysis, > or a number of other things. > > The customer might have a number of these same conveyors on the factory > floor all with the same script behavior(s). The scripts need to be > isolated insofar that when they do turn off the conveyor, as in the > example above, that they turn off the conveyor in the component they are > associated with. So I would have to say that the state of the script > "instance" needs to be separate from each other. > > The scripts don't run all the time. They run once during compilation, > as that's the behavior of CPython. So any statements at the main module > level get executed then. If the script has specific functions defined, > we call those python functions when particular simulation events take place. > > To answer some of your specific questions: > Q1. Do you need multiple system states so they get their own modules, > console, etc... do you need everything in sys isolated? > > A1. I would have to say yes, for the most part. Shallow copies of > imported modules are probably OK, but we aren't far enough into the > migration to give you a definitive answer. There is one case in our C++ > implementation that this caused a problem and we were forced to call the > module's init function for each interpreter behind the scenes. > > As far as everything in sys is concerned, maybe not but I can think of > at least one situation that it must be isolated. Currently, we redirect > sys.stdout and sys.stderr to a window in our application, but that > doesn't stop a user from redefining those manually in one of their > scripts. If they do, then it shouldn't affect any other script in the > application. Other things, like sys.version, don't have to be isolated. > > Q2. Do you need to guarantee the isolation even if .NET code is called > (e.g. they could smuggled data via a static field). > > A2. No and in our case I don't think that would be desirable. The > scripts themselves need to be able to interact with other objects within > the simulation world. > > Q3. If they do need some rather high level of isolation are app domains > good enough? Do you need to marshal a lot of data in/out? Or is the > effort to spin up and use app domains correctly? > > A4. I'm fairly new to .Net, so I'm not sure. I'll have to read up on > app domains, but my gut tells me that is not what we want here. > > > I hope this sheds more light, Dino. I tried to be as clear as possible, > but it was a bit difficult to keep this short(ish) and still convey our > needs. > > Let me know if I can elaborate on any other questions you might have, or > if anything I've wrote here is unclear. > > One thing to think about: eventually we want to make our simulation > engine multi-threaded. Script functions will probably be getting > executed in parallel at some point. > > Thanks, > Tony > > Dino Viehland wrote: >> I'm not actually the one working on the engine APIs so that's the reason I've tended to be vague. I'll talk to the people doing it and let you know what I hear. >> >> But the more info you can give us the better decision we'll be able to make. For example what do you actually need to be isolated? Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? >> >> Ultimately understanding the scenarios where this is being used might end up with us coming up with an even better solution. >> >> The reasons why I ask that is because there are already many options on isolation depending upon what you're trying to do. For example in the dynamic language support for ASP.NET we're executing the same code in multiple modules. That gives each thread it's own set of globals but could allow sharing through system state. It also means that the different requests get to share imported modules. That's not much isolation but it could be enough for a lot of scenarios. On the other extreme is full app domain isolation. >> >> The more info we get here the more likely we'll capture the right result. The real challenge here is it's actually impossible for us to offer full isolation w/o going to app domain isolation. So anything we create will be less; for example Michael Foord noted that the recursion enforcement is a global setting and it's hard to not make that global. So we just need to figure out the right "less" that is both useful, maintainable, and understandable. >> > _______________________________________________ > 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 May 2 21:18:53 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 02 May 2007 20:18:53 +0100 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <7AD436E4270DD54A94238001769C222790ACCE2D49@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638892E.3060300@voidspace.org.uk> <46388AC2.7080301@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACCE2CA0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638B6E7.6000803@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACCE2D49@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <4638E41D.8030607@voidspace.org.uk> Dino Viehland wrote: > I didn't even realize posting at the top was considered a no-no on mailing list etiquette... But indeed, I am using Outlook. I wonder if there's an option to change that somewhere... > I was a bit tongue in cheek - but top-posting suffers from the same readability issues on mailing lists as it does in usenet posts. > Thanks for your feedback Michael. This thread has diverged a little bit so let me know if you have any thoughts on the rest of it. > It occurs to me that your suggestion won't work for us if the user spawns any threads of their own (which is highly likely) - unless we can tell what thread it was spawned from... Meanwhile I'll try and digest the rest of *this* thread... Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Wednesday, May 02, 2007 9:06 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) > > My guess is that you have to use outlook. It does seem to encourage > top-posting. ;-) > > Dino Viehland wrote: > >> The scripts are running on multiple threads? >> > Usually - although sometimes code is executed on the GUI thread, but in > this case we always know where to send the output. > > >> The easy way to do this in v2.0 is to set console output (we no longer maintain our own output streams) to be a stream which looks at a thread static variable which is the real stream to output to. Would that solve the entire isolation problem for you? >> > > > Our current code is nice and elegant, whilst yours sounds hacky. :-p > > Actually its just a solution we didn't think of, although it isn't quite > as nice as running them in separate engines which we do now, and does > give us *some* measure of isolation. (It is slightly less likely that a > badly written user script will now kill the whole application, although > obviously still very easy.) > > > >> The only problem w/ this is if user code sets sys.stdout they'll hijack all the other scripts. >> >> > > Which is a problem - but we can always say "don't do that then"... > > I think we still like our current use of multiple engines, and would > prefer to see that supported in IronPython 2.0, even with a shared > SystemState. > > At least you have given us an alternative without *having* to use > AppDomains if this isn't possible. > > Thanks > > Michael Foord > http://www.voidspace.org.uk/ironpython/index.shtml > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Wednesday, May 02, 2007 5:58 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) >> >> Michael Foord wrote: >> >> >>> Dino Viehland wrote: >>> >>> >>> >>>> I'm not actually the one working on the engine APIs so that's the reason I've tended to be vague. I'll talk to the people doing it and let you know what I hear. >>>> >>>> But the more info you can give us the better decision we'll be able to make. For example what do you actually need to be isolated? Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? >>>> >>>> >>>> >>>> >>> At Resolver we are currently using multiple IronPython engines. Moving >>> to AppDomains is a long term goal for us, but is actually quite a lot of >>> work (we would have *lots* of cross-domain calls and so to avoid that we >>> have to find an efficient way of pumping lots of data in and then out of >>> the app domain). >>> >>> Switching to app domains is not a high priority task for us, and in the >>> meantime we *can't* upgrade to IronPython 2 if it doesn't support >>> multiple engines. >>> >>> Isolation of engines is only a minor benefit (it is a positive side >>> effect - but not the reason we started using them) for us at the moment, >>> and an isolated system state (although nice) is not vital. >>> >>> >>> >>> >> In fact, the reason we started using multiple engines was to divert the >> standard output of simultaneously running user scripts to different >> output windows... >> >> Michael >> >> >> >> >>> All the best, >>> >>> Michael Foord >>> http://www.voidspace.org.uk/ironpython/index.shtml >>> >>> _______________________________________________ >>> 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 Martin.Maly at microsoft.com Wed May 2 21:58:27 2007 From: Martin.Maly at microsoft.com (Martin Maly) Date: Wed, 2 May 2007 12:58:27 -0700 Subject: [IronPython] DLR and VS-Interactive In-Reply-To: <005801c78c56$1bf2edd0$6400a8c0@numericedge01> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk><7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <005801c78c56$1bf2edd0$6400a8c0@numericedge01> Message-ID: The "VS Interactive" as you call it, or perhaps simply a good interactive development experience is an integral part of the dynamic language world. The VS SDK IronPython sample which demonstrates hosting of IronPython within Visual Studio offers a small glimpse one direction, the new Silverlight DLR Console sample that Keith pointed out is a glimpse different direction. There are lots of other possibilities as well. For example the ASP.NET futures Visual Studio integration (http://www.microsoft.com/downloads/details.aspx?FamilyId=9323777E-FE78-430C-AD92-D5BE5B5EAD98&displaylang=en) goes a little further than the IronPython VS integration sample which has been part of the VS SDK for a while (and which has been the initial exploration into static analysis and intellisense support for Python in the editor, rather than analyzing dynamically executing state). The ASP.NET Futures now has slightly more intellisense support - for controls that are present in the HTML markup, and the Request and Response objects. For example if you have text box in the HTML markup called "text1", you can type text1 (dot) and get completion help inside Python. This is another direction altogether, and they are all challenging and interesting. To answer the original question which direction the refactoring is headed ... right now all the focus is on the runtime itself, so the only fair answer I can give is: "I really don't know yet", but once the runtime has solidified, it seems that the languages benefiting from executing on the runtime would like to benefit from common hosting or some kind of interactive development experience that you are envisioning. Martin -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeffrey Sax Sent: Tuesday, May 01, 2007 6:06 PM To: 'Discussion of IronPython' Subject: [IronPython] DLR and VS-Interactive This is more a DLR than an IronPython question. There are two 'dynamic' aspects that are covered by the DLR extension to the CLR. One is runtime support for efficient dynamic typing. The other is the hosting side: console interface, integration with Visual Studio, etc. These are useful for other (non-dynamic) languages as well. Case in point: F# has an interactive console in Visual Studio, but is compiled and statically typed. This second aspect looks more like an extension of the Visual Studio SDK, if it wasn't taken straight from the VS Integration samples from the VS SDK. In other words: my impression is that the current DLR is made up of two separable parts: 1. The actual DLR, which enables efficient dynamic typing on the CLR. 2. "VS-Interactive", a set of extensions to the Visual Studio SDK that turn Visual Studio into an interactive development environment. Is this where the refactoring is headed? Jeffrey Sax Extreme Optimization _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Wed May 2 22:47:42 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 2 May 2007 13:47:42 -0700 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <4638E41D.8030607@voidspace.org.uk> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <463682AA.60806@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACF7A47B@DF-GRTDANE-MSG.exchange.corp.microsoft.com>, <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638892E.3060300@voidspace.org.uk> <46388AC2.7080301@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACCE2CA0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638B6E7.6000803@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACCE2D49@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638E41D.8030607@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222790ACCE2E33@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Both you and Tony bring up a very good point. I believe that we can solve the thread problem by using .NET's ExecutionContext. I've never actually tried that, I just know it exists, so I'll need to look into that. That will cause the context to be flown to thread pool threads, newly created threads, and other various async points within the CLR. One reason for its existence today is for security so the CLR is pretty good at making sure this always gets flowed (there are various ways to do operations which don't flow it, but they all have "Unsafe" in their name). Based upon Tony's description of I'm starting to believe the swappable SystemStates rather than multiple PythonEngines are the right solution - especially given that CPython is using a similar technique and even more so if ExecutionContext solves the async/threading problem. Thanks for all your feedback and let me know if you have any more. I'll take it all to our discussion about the hosting APIs next week. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Wednesday, May 02, 2007 12:19 PM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Dino Viehland wrote: > I didn't even realize posting at the top was considered a no-no on mailing list etiquette... But indeed, I am using Outlook. I wonder if there's an option to change that somewhere... > I was a bit tongue in cheek - but top-posting suffers from the same readability issues on mailing lists as it does in usenet posts. > Thanks for your feedback Michael. This thread has diverged a little bit so let me know if you have any thoughts on the rest of it. > It occurs to me that your suggestion won't work for us if the user spawns any threads of their own (which is highly likely) - unless we can tell what thread it was spawned from... Meanwhile I'll try and digest the rest of *this* thread... Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Wednesday, May 02, 2007 9:06 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) > > My guess is that you have to use outlook. It does seem to encourage > top-posting. ;-) > > Dino Viehland wrote: > >> The scripts are running on multiple threads? >> > Usually - although sometimes code is executed on the GUI thread, but in > this case we always know where to send the output. > > >> The easy way to do this in v2.0 is to set console output (we no longer maintain our own output streams) to be a stream which looks at a thread static variable which is the real stream to output to. Would that solve the entire isolation problem for you? >> > > > Our current code is nice and elegant, whilst yours sounds hacky. :-p > > Actually its just a solution we didn't think of, although it isn't quite > as nice as running them in separate engines which we do now, and does > give us *some* measure of isolation. (It is slightly less likely that a > badly written user script will now kill the whole application, although > obviously still very easy.) > > > >> The only problem w/ this is if user code sets sys.stdout they'll hijack all the other scripts. >> >> > > Which is a problem - but we can always say "don't do that then"... > > I think we still like our current use of multiple engines, and would > prefer to see that supported in IronPython 2.0, even with a shared > SystemState. > > At least you have given us an alternative without *having* to use > AppDomains if this isn't possible. > > Thanks > > Michael Foord > http://www.voidspace.org.uk/ironpython/index.shtml > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Wednesday, May 02, 2007 5:58 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) >> >> Michael Foord wrote: >> >> >>> Dino Viehland wrote: >>> >>> >>> >>>> I'm not actually the one working on the engine APIs so that's the reason I've tended to be vague. I'll talk to the people doing it and let you know what I hear. >>>> >>>> But the more info you can give us the better decision we'll be able to make. For example what do you actually need to be isolated? Do you need multiple system states so they get their own modules, console, etc... do you need everything in sys isolated? Do you need to guarantee the isolation even if .NET code is called (e.g. they could smuggled data via a static field). If they do need some rather high level of isolation are app domains good enough? Do you need to marshal a lot of data in/out? Or is the effort to spin up and use app domains correctly? >>>> >>>> >>>> >>>> >>> At Resolver we are currently using multiple IronPython engines. Moving >>> to AppDomains is a long term goal for us, but is actually quite a lot of >>> work (we would have *lots* of cross-domain calls and so to avoid that we >>> have to find an efficient way of pumping lots of data in and then out of >>> the app domain). >>> >>> Switching to app domains is not a high priority task for us, and in the >>> meantime we *can't* upgrade to IronPython 2 if it doesn't support >>> multiple engines. >>> >>> Isolation of engines is only a minor benefit (it is a positive side >>> effect - but not the reason we started using them) for us at the moment, >>> and an isolated system state (although nice) is not vital. >>> >>> >>> >>> >> In fact, the reason we started using multiple engines was to divert the >> standard output of simultaneously running user scripts to different >> output windows... >> >> Michael >> >> >> >> >>> All the best, >>> >>> Michael Foord >>> http://www.voidspace.org.uk/ironpython/index.shtml >>> >>> _______________________________________________ >>> 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 tstrimple at collectivedata.com Thu May 3 17:19:02 2007 From: tstrimple at collectivedata.com (Timothy Strimple) Date: Thu, 3 May 2007 10:19:02 -0500 Subject: [IronPython] Persistent IronPython Environment Message-ID: <002c01c78d96$61934240$24b9c6c0$@com> I'm trying to setup a persistent IronPython environment but I'm not sure where to start. I would like to be able to do something like the following. PythonEngine engine = new PythonEngine(); engine.Execute("x = 12"); engine.Execute("Print x"); Currently everything I have tried throws an exception since the first statement isn't maintained within the engine. I've tried using ParseInteractiveInput and can't seem to get that to work as desired either. Any help would be greatly appreciated. Tim. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu May 3 17:16:21 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 03 May 2007 16:16:21 +0100 Subject: [IronPython] Persistent IronPython Environment In-Reply-To: <002c01c78d96$61934240$24b9c6c0$@com> References: <002c01c78d96$61934240$24b9c6c0$@com> Message-ID: <4639FCC5.6090308@voidspace.org.uk> An HTML attachment was scrubbed... URL: From tstrimple at collectivedata.com Thu May 3 17:24:34 2007 From: tstrimple at collectivedata.com (Timothy Strimple) Date: Thu, 3 May 2007 10:24:34 -0500 Subject: [IronPython] Persistent IronPython Environment In-Reply-To: <4639FCC5.6090308@voidspace.org.uk> References: <002c01c78d96$61934240$24b9c6c0$@com> <4639FCC5.6090308@voidspace.org.uk> Message-ID: <004401c78d97$2792f8f0$76b8ead0$@com> How embarrassing. The exception kept saying unexpected token x, so I assumed that x was the problem. Thanks for the quick reply! Tim. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, May 03, 2007 10:16 AM To: Discussion of IronPython Subject: Re: [IronPython] Persistent IronPython Environment engine.Execute("print x"); Note the lowercase 'p' in print. As they execute in the default module I would expect this to work. Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml Currently everything I have tried throws an exception since the first statement isn't maintained within the engine. I've tried using ParseInteractiveInput and can't seem to get that to work as desired either. Any help would be greatly appreciated. Tim. _____ _______________________________________________ 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 mbelugin at gmail.com Fri May 4 07:11:44 2007 From: mbelugin at gmail.com (Max Belugin) Date: Fri, 4 May 2007 09:11:44 +0400 Subject: [IronPython] Did you find any purpose to compile IronPython code to DLL using pyc.py Message-ID: <86aeb4640705032211n79250ed5la9f2e5259d429621@mail.gmail.com> I am trying to implement plugin for FarManager file manager using IronPython The plugin is the dll with a class implementing special interface. I haven't find a way to build such dll by pyc.py so I decide to write a wrapper (it is available from http://code.google.com/p/farnet/ ) ) But now is my question: can i decrease startup time using precompilation? Or how dll compilation is intended to be used? -- Max Belugin, http://belugin.info , ICQ:9406811 From fuzzyman at voidspace.org.uk Fri May 4 14:04:43 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 04 May 2007 13:04:43 +0100 Subject: [IronPython] Did you find any purpose to compile IronPython code to DLL using pyc.py In-Reply-To: <86aeb4640705032211n79250ed5la9f2e5259d429621@mail.gmail.com> References: <86aeb4640705032211n79250ed5la9f2e5259d429621@mail.gmail.com> Message-ID: <463B215B.6040804@voidspace.org.uk> Max Belugin wrote: > I am trying to implement plugin for FarManager file manager using IronPython > > The plugin is the dll with a class implementing special interface. > > I haven't find a way to build such dll by pyc.py so I decide to write a wrapper > (it is available from http://code.google.com/p/farnet/ ) > ) > > But now is my question: can i decrease startup time using precompilation? > Or how dll compilation is intended to be used? > We experimented with precompiling all of our code to see if it would help with startup time. (Our application is around 20 000 lines of Python code - most of which is imported at started.) The results surprised us, out of a 50 second startup (which is too long), precompiling saved us only six seconds. This was unfortunate, but on the plus side it means that IronPython is pretty fast at parsing and compiling Python code... Precompiling also allows you to do 'binary-only' distributions, but that isn't something we particularly need (at the moment...). Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml From mbelugin at gmail.com Fri May 4 14:30:55 2007 From: mbelugin at gmail.com (Max Belugin) Date: Fri, 4 May 2007 16:30:55 +0400 Subject: [IronPython] Did you find any purpose to compile IronPython code to DLL using pyc.py In-Reply-To: <463B215B.6040804@voidspace.org.uk> References: <86aeb4640705032211n79250ed5la9f2e5259d429621@mail.gmail.com> <463B215B.6040804@voidspace.org.uk> Message-ID: <86aeb4640705040530n33bd3790m6ec2c599f238f36d@mail.gmail.com> Thank you Michael, can you show me example of using that precomiled code? How to use those dlls from python or C# On 5/4/07, Michael Foord wrote: > We experimented with precompiling all of our code to see if it would > help with startup time. -- Max Belugin, http://belugin.info , ICQ:9406811 From fuzzyman at voidspace.org.uk Fri May 4 14:31:09 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 04 May 2007 13:31:09 +0100 Subject: [IronPython] Did you find any purpose to compile IronPython code to DLL using pyc.py In-Reply-To: <86aeb4640705040530n33bd3790m6ec2c599f238f36d@mail.gmail.com> References: <86aeb4640705032211n79250ed5la9f2e5259d429621@mail.gmail.com> <463B215B.6040804@voidspace.org.uk> <86aeb4640705040530n33bd3790m6ec2c599f238f36d@mail.gmail.com> Message-ID: <463B278D.4000509@voidspace.org.uk> Max Belugin wrote: > Thank you Michael, can you show me example of using that precomiled > code? How to use those dlls from python or C# > From Python you just use the normal import statements. You can verify this by deleting the source files after compilation. You can't use them directly from C# - but must write stub classes that call into the IronPython engine. Michael > On 5/4/07, Michael Foord wrote: > >> We experimented with precompiling all of our code to see if it would >> help with startup time. >> From mbelugin at gmail.com Fri May 4 14:43:50 2007 From: mbelugin at gmail.com (Max Belugin) Date: Fri, 4 May 2007 16:43:50 +0400 Subject: [IronPython] Did you find any purpose to compile IronPython code to DLL using pyc.py In-Reply-To: <463B278D.4000509@voidspace.org.uk> References: <86aeb4640705032211n79250ed5la9f2e5259d429621@mail.gmail.com> <463B215B.6040804@voidspace.org.uk> <86aeb4640705040530n33bd3790m6ec2c599f238f36d@mail.gmail.com> <463B278D.4000509@voidspace.org.uk> Message-ID: <86aeb4640705040543k2185f889x2c2e9b623de4f857@mail.gmail.com> Can you get me some advice about decreasing startup time? Should I use one engine with multiple modules or multiple engines? What sre perspectives? Will DLR solve this prproblem? This is source of my loader (I am creating one engine instace for each script): using FarManager; using System.Reflection; using System.Collections; using System.Collections.Generic; using System.IO; using IronPython.Hosting; using IronPython.Modules; public class IronPythonLoader : BasePlugin { protected string PluginFile(string name) { FileInfo fi=new FileInfo(Assembly.GetExecutingAssembly().Location); return fi.Directory.Parent.FullName+"\\"+name; } protected void LoadScript(string fileName) { PythonEngine engine = new PythonEngine(); engine.AddToPath(Path.GetDirectoryName(fileName)); engine.Import("site"); ClrModule clr = (ClrModule)engine.Import("clr"); EngineModule engineModule = engine.CreateModule("__main__", false); engine.DefaultModule = engineModule; clr.AddReferenceByPartialName("FarNetIntf"); engine.Import("FarManager"); engine.Globals["far"] = Far; engine.ExecuteFile(fileName); } override public void Connect() { string scriptsFolder = PluginFile("Scripts"); foreach(FileInfo file in new DirectoryInfo(scriptsFolder).GetFiles()) LoadScript(file.FullName); } } On 5/4/07, Michael Foord wrote: > Max Belugin wrote: > > Thank you Michael, can you show me example of using that precomiled > > code? How to use those dlls from python or C# > > > From Python you just use the normal import statements. You can verify > this by deleting the source files after compilation. > > You can't use them directly from C# - but must write stub classes that > call into the IronPython engine. > > Michael > > > On 5/4/07, Michael Foord wrote: > > > >> We experimented with precompiling all of our code to see if it would > >> help with startup time. > >> > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Max Belugin, http://belugin.info , ICQ:9406811 From fuzzyman at voidspace.org.uk Sat May 5 01:24:55 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 05 May 2007 00:24:55 +0100 Subject: [IronPython] DLR Console Bugs Message-ID: <463BC0C7.2040606@voidspace.org.uk> Hello all, So where do I report bugs in the DLR Console? For example it doesn't recognise a UK keyboard, so I can't type any underscores and have to guess the location of other keys... Still having fun though. :-) All the best, Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml From sanxiyn at gmail.com Sat May 5 16:59:24 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sat, 5 May 2007 23:59:24 +0900 Subject: [IronPython] Dynamic Language Runtime, Adapters and Navigators Message-ID: <5b0248170705050759v45ac78bfv272757cde0e57058@mail.gmail.com> To all those who are following Dynamic Language Runtime articles on Jim's Thinking Dynamic, I think this article from Attila Szegedi captures the main idea very nicely, and I actually like his terminologies better. (I mean, compared to "One True Object", which sounds rather silly...) Note: Szegedi is the current maintainer of Mozilla Rhino, JavaScript implementation for JVM, so his article uses examples from JVM. In-process cross-language object interaction: adapters or navigators? http://www.szegedi.org/articles/wrappersOrNavigators.html What do you think? -- Seo Sanghyeon From xmlhacker at gmail.com Sat May 5 18:01:26 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sat, 5 May 2007 10:01:26 -0600 Subject: [IronPython] Dynamic Language Runtime, Adapters and Navigators In-Reply-To: <5b0248170705050759v45ac78bfv272757cde0e57058@mail.gmail.com> References: <5b0248170705050759v45ac78bfv272757cde0e57058@mail.gmail.com> Message-ID: agents On 5/5/07, Sanghyeon Seo wrote: > > To all those who are following Dynamic Language Runtime articles on > Jim's Thinking Dynamic, > > I think this article from Attila Szegedi captures the main idea very > nicely, and I actually like his terminologies better. (I mean, > compared to "One True Object", which sounds rather silly...) > > Note: Szegedi is the current maintainer of Mozilla Rhino, JavaScript > implementation for JVM, so his article uses examples from JVM. > > In-process cross-language object interaction: adapters or navigators? > http://www.szegedi.org/articles/wrappersOrNavigators.html > > What do you think? > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmlhacker at gmail.com Sat May 5 18:14:08 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sat, 5 May 2007 10:14:08 -0600 Subject: [IronPython] Dynamic Language Runtime, Adapters and Navigators In-Reply-To: References: <5b0248170705050759v45ac78bfv272757cde0e57058@mail.gmail.com> Message-ID: expanding this a bit, via an IM w/ Seo (this will sound a bit familiar, Seo ;-)) personally, I really like the term "agent" as, to me anyway, it adds a later > of implied security e.g. "to talk to me you must go through my agent" > > it also implies a sense of communication rather than adaptation or > translation > > I'm a *BIG* fan of Smalltalk, so that's probably where my preference stems > from Adding a bit to this, when I think of the CLR I think of CIL, and CIL is, quite obviously, the Lingua Franca of the .NET platform. If you can speak CIL, you can speak to the CLR, and if you can speak to the CLR, you don't need to do any translation between languages. The CLR will do that for you. Maybe it's the abstractionist in me, but anytime you can take focus away from a task that sounds difficult (e.g. translation) and focus instead on what you are truly attempting to accomplish (e.g. communication between objects), your going to be a more productive programmer as you can stop thinking in terms of "how can I say this in a way you will understand" and instead "here's my message. what say ye in return?" :D On 5/5/07, M. David Peterson wrote: > > agents > > On 5/5/07, Sanghyeon Seo wrote: > > > > To all those who are following Dynamic Language Runtime articles on > > Jim's Thinking Dynamic, > > > > I think this article from Attila Szegedi captures the main idea very > > nicely, and I actually like his terminologies better. (I mean, > > compared to "One True Object", which sounds rather silly...) > > > > Note: Szegedi is the current maintainer of Mozilla Rhino, JavaScript > > implementation for JVM, so his article uses examples from JVM. > > > > In-process cross-language object interaction: adapters or navigators? > > http://www.szegedi.org/articles/wrappersOrNavigators.html > > > > What do you think? > > > > -- > > Seo Sanghyeon > > _______________________________________________ > > users mailing list > > users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > -- > /M:D > > M. David Peterson > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | > http://dev.aol.com/blog/3155 -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmlhacker at gmail.com Sat May 5 18:50:50 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sat, 5 May 2007 10:50:50 -0600 Subject: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) In-Reply-To: <7AD436E4270DD54A94238001769C222790ACCE2E33@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222790ACCE250E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4637B508.4070001@v-sim.com> <7AD436E4270DD54A94238001769C222790ACF7A47E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638892E.3060300@voidspace.org.uk> <46388AC2.7080301@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACCE2CA0@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638B6E7.6000803@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACCE2D49@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <4638E41D.8030607@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790ACCE2E33@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: On 5/2/07, Dino Viehland wrote: > > Both you and Tony bring up a very good point. I believe that we can solve > the thread problem by using .NET's ExecutionContext. I've never actually > tried that, I just know it exists, so I'll need to look into that. That will > cause the context to be flown to thread pool threads, newly created threads, > and other various async points within the CLR. One reason for its existence > today is for security so the CLR is pretty good at making sure this always > gets flowed (there are various ways to do operations which don't flow it, > but they all have "Unsafe" in their name). > > Based upon Tony's description of I'm starting to believe the swappable > SystemStates rather than multiple PythonEngines are the right solution - > especially given that CPython is using a similar technique and even more so > if ExecutionContext solves the async/threading problem. I wonder if Joe Duffy and his work with PLINQ might be able to help solve some of these issues (at least the issues involving the need for concurrent operations) while at the same time provide a nice pathway to integrated and direct support for LINQ inside of IP? Thinking in terms of a parallel-processing empowered IP engine taking on the role of a dispatcher, multiple consoles could exist, each of which could be spawned in an isolated or shared state at run time. With nothing more than the knowledge of the handle that made the request this same parallel-processing empowered IP engine could do some *MIGHTY* things. -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From drew at astro.pas.rochester.edu Sun May 6 23:04:50 2007 From: drew at astro.pas.rochester.edu (drew moore) Date: Sun, 06 May 2007 17:04:50 -0400 Subject: [IronPython] Immutable value types, again In-Reply-To: <463BC0C7.2040606@voidspace.org.uk> References: <463BC0C7.2040606@voidspace.org.uk> Message-ID: <463E42F2.6070100@astro.pas.rochester.edu> Hi guys! I recently wrote some (pure CPython!) code that allows the user to get and set a vector (3d point) via a property that wraps an inner vector value with a coordinate transformation. For the most part, it does the right thing, but client code like: model.point.X = 3.5 does not do the right thing. The point property returns a brand new vector, its X attribute is modified, and then the whole thing is garbage collected. Oops, but no big deal. Once you remember that it works that way, you code appropriately. It makes sense when you understand what's happening. I also recently tried to use a (proprietary) 3D library with IronPython. While I was able to see the vector structure that was exposed in the tlbimp.exe - created .NET assembly (kudos to IronPython -- this same struct is invisible to CPython's win32com, since it has no guid) I could not find a way to actually modify the members of this struct. I had to write some C# to get the job done. Hey, we're all consenting adults here... Where the heck is the object.__setattr__ way to change one of these "mostly immutable" .NET value types? I couldn't find it. Well, I found a way to add a guid and get the COM stuff working, and when I got my CPython code connected to the same struct, it was mutable. Yay! Of course, it was a copy, so the same misbehavior could happen in a containment situation. The thing is, I found "possibly making a coding mistake" preferable to "having something be impossible to do in IronPython when it's possible in all the other .NET languages". (I *rarely* find myself needing to explain why something is impossible to do in Python! WTF??) This was my first honest attempt to do something "real" with IronPython. First impressions, guys... Of course, I might be missing something too, so clue me in if I am doing something stupid.. Nutshell? I'm not sure that the "draconian" immutable value types decision, although well-intentioned, was the Pythonic thing to do. It prevents you from making a coding mistake that you can make very easily in pure CPython, and it prevents a whole lot more as well. Am I the only one, or has anyone else bumped into this one? Is there a "mutable value types" switch that I don't know about? Is there another back door into these objects, or do I need to wait for ctypes in IronPython? cheers Drew From redmoon17 at gmail.com Mon May 7 03:59:49 2007 From: redmoon17 at gmail.com (Kevin Chu) Date: Mon, 7 May 2007 09:59:49 +0800 Subject: [IronPython] property bug? or my mistake? Message-ID: <41d7f4a90705061859t4d0e8b3ah3631df6b0fa416b7@mail.gmail.com> I do this walkthought: http://quickstarts.asp.net/Futures/dlr/doc/dlsharedcode.aspx but when I change some code ,want to get Upper string, but my code is not working my code is: class SampleClass: "Sample class with one property" def __init__(self): self.__testString = "" def SetTestString(self, value): self.__testString = value.upper() def GetTestString(self): return self.__testString TestString = property(GetTestString, SetTestString) or class SampleClass: "Sample class with one property" def __init__(self): self.__testString = "" def SetTestString(self, value): self.__testString = str(value).upper() def GetTestString(self): return self.__testString TestString = property(GetTestString, SetTestString) or class SampleClass: "Sample class with one property" def __init__(self): self.__testString = "" def SetTestString(self, value): self.__testString = value def GetTestString(self): return self.__testString.upper() TestString = property(GetTestString, SetTestString) -- Once in a Redmoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Mon May 7 04:09:57 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Sun, 6 May 2007 19:09:57 -0700 Subject: [IronPython] property bug? or my mistake? In-Reply-To: <41d7f4a90705061859t4d0e8b3ah3631df6b0fa416b7@mail.gmail.com> References: <41d7f4a90705061859t4d0e8b3ah3631df6b0fa416b7@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222790ACF7A483@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Your class needs to inherit from object for properies (and descriptors in general) to work: class SampleClass(object): "Sample class with one property" def __init__(self): self.__testString = "" def SetTestString(self, value): self.__testString = value.upper () def GetTestString(self): return self.__testString TestString = property(GetTestString, SetTestString) ________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Kevin Chu [redmoon17 at gmail.com] Sent: Sunday, May 06, 2007 6:59 PM To: Discussion of IronPython Subject: [IronPython] property bug? or my mistake? I do this walkthought: http://quickstarts.asp.net/Futures/dlr/doc/dlsharedcode.aspx but when I change some code ,want to get Upper string, but my code is not working my code is: class SampleClass: "Sample class with one property" def __init__(self): self.__testString = "" def SetTestString(self, value): self.__testString = value.upper () def GetTestString(self): return self.__testString TestString = property(GetTestString, SetTestString) or class SampleClass: "Sample class with one property" def __init__(self): self.__testString = "" def SetTestString(self, value): self.__testString = str(value).upper() def GetTestString(self): return self.__testString TestString = property(GetTestString, SetTestString) or class SampleClass: "Sample class with one property" def __init__(self): self.__testString = "" def SetTestString(self, value): self.__testString = value def GetTestString(self): return self.__testString.upper() TestString = property(GetTestString, SetTestString) -- Once in a Redmoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From redmoon17 at gmail.com Mon May 7 04:51:34 2007 From: redmoon17 at gmail.com (Kevin Chu) Date: Mon, 7 May 2007 10:51:34 +0800 Subject: [IronPython] property bug? or my mistake? In-Reply-To: <7AD436E4270DD54A94238001769C222790ACF7A483@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <41d7f4a90705061859t4d0e8b3ah3631df6b0fa416b7@mail.gmail.com> <7AD436E4270DD54A94238001769C222790ACF7A483@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <41d7f4a90705061951g1186841cwd61c5d9a21bde2bb@mail.gmail.com> thanks a lot On 5/7/07, Dino Viehland wrote: > > Your class needs to inherit from object for properies (and descriptors in > general) to work: > > class SampleClass(object): > "Sample class with one property" > def __init__(self): > self.__testString = "" > def SetTestString(self, value): > self.__testString = value.upper () > def GetTestString(self): > return self.__testString > TestString = property(GetTestString, SetTestString) > ------------------------------ > *From:* users-bounces at lists.ironpython.com [ > users-bounces at lists.ironpython.com] On Behalf Of Kevin Chu [ > redmoon17 at gmail.com] > *Sent:* Sunday, May 06, 2007 6:59 PM > *To:* Discussion of IronPython > *Subject:* [IronPython] property bug? or my mistake? > > > I do this walkthought: > http://quickstarts.asp.net/Futures/dlr/doc/dlsharedcode.aspx > but when I change some code ,want to get Upper string, but my code is not > working > my code is: > > class SampleClass: > "Sample class with one property" > def __init__(self): > self.__testString = "" > def SetTestString(self, value): > self.__testString = value.upper () > def GetTestString(self): > return self.__testString > TestString = property(GetTestString, SetTestString) > or > > class SampleClass: > "Sample class with one property" > def __init__(self): > self.__testString = "" > def SetTestString(self, value): > self.__testString = str(value).upper() > def GetTestString(self): > return self.__testString > TestString = property(GetTestString, SetTestString) > > or > > class SampleClass: > "Sample class with one property" > def __init__(self): > self.__testString = "" > def SetTestString(self, value): > self.__testString = value > def GetTestString(self): > return self.__testString.upper() > TestString = property(GetTestString, SetTestString) > -- > Once in a Redmoon > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- Once in a Redmoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at notcharles.ca Mon May 7 04:58:51 2007 From: joe at notcharles.ca (Joe Mason) Date: Sun, 06 May 2007 22:58:51 -0400 Subject: [IronPython] IronPython 2.0 Alpha 1 on Mono Message-ID: <20070507025851.GA28407@notcharles.ca> Sanghyeon Seo wrote: > After these, gmcs crashes inside Mono runtime with backtrace pointing > to custom attribute resolution. Still investigating, but above three > patches should help anyone trying to dig this on their own together > with me. :) The crash I'm getting is: ** ERROR **: file reflection.c: line 2211 (create_typespec): assertion failed: (p-sig < 128) aborting... Stacktrace: at (wrapper managed-to-native) System.Reflection.Emit.ModuleBuilder.getToken (System.Reflection.Emit.ModuleBuilder,object) <0x00004> at (wrapper managed-to-native) System.Reflection.Emit.ModuleBuilder.getToken (System.Reflection.Emit.ModuleBuilder,object) <0xffffffff> at System.Reflection.Emit.ModuleBuilder.GetToken (System.Reflection.MemberInfo) <0x0000d> at System.Reflection.Emit.ModuleBuilderTokenGenerator.GetToken (System.Reflection.MemberInfo) <0x00016> ... It's in Tuple.cs, which is full of autogenerated code: public static Type GetTupleType(int size) { #region Generated Tuple Get From Size // *** BEGIN GENERATED CODE *** if (size <= 128) { if (size <= 1) { return typeof(Tuple<>); Looks like Mono has a limit of 128 properties per object, and since each Tuple has a get and set property for each individual element, you can only have 64 elements, not 128 as the file tries to define. (Even 64 crashed, so there must be some other property slots taken up by something I'm not aware of. It compiled when I deleted the last two Tuple classes in the file, the ones with more than 32 template parameters, making the max tuple size 32, and adjusted the GetTupleType function to max out at 32 as well. (I also had to adjust CodeBlock.Generated.cs to match - the change to make was obvious from the error messages.) That was enough to get Microsoft.Scripting.dll to build. Microsoft.Scripting.Vestigial.dll keeps giving me "error CS8100: Internal error: could not find Invoke method!" Haven't started to look at that yet. (I haven't gotten around to building mono from svn like you mentioned - I just took out the "[NotNull]" constraints for now - so this might even be fixed already.) Joe From sanxiyn at gmail.com Mon May 7 05:13:16 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 7 May 2007 12:13:16 +0900 Subject: [IronPython] IronPython 2.0 Alpha 1 on Mono In-Reply-To: <20070507025851.GA28407@notcharles.ca> References: <20070507025851.GA28407@notcharles.ca> Message-ID: <5b0248170705062013x2a509e69g6a1136f54fde702d@mail.gmail.com> Patch repository: https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/2.0a1/ 2007/5/7, Joe Mason : > Looks like Mono has a limit of 128 properties per object, (...) Thanks a *lot* for investigating this! Actually, this "128 properties" bug is fixed in Mono SVN, so I didn't experience this. > That was enough to get Microsoft.Scripting.dll to build. > Microsoft.Scripting.Vestigial.dll keeps giving me "error CS8100: > Internal error: could not find Invoke method!" Haven't started to look > at that yet. This error can be avoided by patch-delegate-conversion I posted. Can you try it? > (I haven't gotten around to building mono from svn like > you mentioned - I just took out the "[NotNull]" constraints for now - so > this might even be fixed already.) No, "could not find Invoke" error is not yet fixed in SVN. Also, I posted patch-r76552 for people using released version of Mono and not SVN version. This simply removes all [NotNull] constraints for you. SVN revision after 76552 doesn't need the patch. -- Seo Sanghyeon From joe at notcharles.ca Mon May 7 06:21:29 2007 From: joe at notcharles.ca (Joe Mason) Date: Mon, 07 May 2007 00:21:29 -0400 Subject: [IronPython] IronPython 2.0 Alpha 1 on Mono In-Reply-To: <5b0248170705062013x2a509e69g6a1136f54fde702d@mail.gmail.com> References: <20070507025851.GA28407@notcharles.ca> <5b0248170705062013x2a509e69g6a1136f54fde702d@mail.gmail.com> Message-ID: <20070507042129.GA29217@notcharles.ca> On Mon, May 07, 2007 at 12:13:16PM +0900, Sanghyeon Seo wrote: > Actually, this "128 properties" bug is fixed in Mono SVN, so I didn't > experience this. Well, I guess just I wasted a bunch of my time, then... I just finished building mono from SVN, and I think I now get the same patch you do. > > That was enough to get Microsoft.Scripting.dll to build. > > Microsoft.Scripting.Vestigial.dll keeps giving me "error CS8100: > > Internal error: could not find Invoke method!" Haven't started to look > > at that yet. > > This error can be avoided by patch-delegate-conversion I posted. > Can you try it? Yep, with current mono SVN and your delegate-conversion patch I get this crash somewhere in Microsoft.Scripting.Vestigial: at (wrapper managed-to-native) System.MonoCustomAttrs.GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool) <0x00004> at (wrapper managed-to-native) System.MonoCustomAttrs.GetCustomAttributesInternal (System.Reflection.ICustomAttributeProvider,System.Type,bool) <0xffffffff> ... which I assume is the same one you saw. I'll look at it some more tomorrow. Joe From dinov at exchange.microsoft.com Tue May 8 00:53:51 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 7 May 2007 15:53:51 -0700 Subject: [IronPython] DLR Console Bugs In-Reply-To: <463BC0C7.2040606@voidspace.org.uk> References: <463BC0C7.2040606@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222790AD2C95AD@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I think www.codeplex.com/DynamicSilverlight is the best spot for these. Thanks! -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, May 04, 2007 4:25 PM To: Discussion of IronPython Subject: [IronPython] DLR Console Bugs Hello all, So where do I report bugs in the DLR Console? For example it doesn't recognise a UK keyboard, so I can't type any underscores and have to guess the location of other keys... Still having fun though. :-) All the best, Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Tue May 8 01:02:57 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 08 May 2007 00:02:57 +0100 Subject: [IronPython] DLR Console Bugs In-Reply-To: <7AD436E4270DD54A94238001769C222790AD2C95AD@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <463BC0C7.2040606@voidspace.org.uk> <7AD436E4270DD54A94238001769C222790AD2C95AD@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <463FB021.4080208@voidspace.org.uk> Dino Viehland wrote: > I think www.codeplex.com/DynamicSilverlight is the best spot for these. Thanks! > Ah - good idea. :-) Done. Michael http://www.voidspace.org.uk/ironpython/index.shtml > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, May 04, 2007 4:25 PM > To: Discussion of IronPython > Subject: [IronPython] DLR Console Bugs > > Hello all, > > So where do I report bugs in the DLR Console? > > For example it doesn't recognise a UK keyboard, so I can't type any > underscores and have to guess the location of other keys... > > Still having fun though. :-) > > All the best, > > Michael Foord > http://www.voidspace.org.uk/ironpython/index.shtml > _______________________________________________ > 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 Thu May 10 12:40:24 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Thu, 10 May 2007 11:40:24 +0100 Subject: [IronPython] SyntaxError: yield in more than one try blocks Message-ID: <4642F698.6060804@defuze.org> sylvain at 4[WebApp]$ mono bin/ipy.exe IronPython 1.1 (1.1) on .NET 2.0.50727.42 def test(): try: yield 1 except: try: yield 2 except: pass if __name__ == '__main__': for _ in test(): print _ Will produce: sylvain at 4[WebApp]$ mono bin/ipy.exe -X:Python25 testyield.py Traceback (most recent call last): SyntaxError: yield in more than one try blocks (testyield.py, line 6) It does work fine with CPython 2.5 - Sylvain From jeff at taupro.com Thu May 10 15:22:54 2007 From: jeff at taupro.com (Jeff Rush) Date: Thu, 10 May 2007 08:22:54 -0500 Subject: [IronPython] A Few Questions for the Python Community re Survey Response Message-ID: <46431CAE.1010709@taupro.com> The official Forrester Research survey form on dynamic languages has arrived and as advocacy coordinator, I'm starting to fill it in. Here are some questions on which I could use some input. Please reply via private email, to avoid cluttering the lists and cross-posting issues, and I'll collate all responses. *Note* that we want the survey to address cPython, IronPython and Jython, so add caveats as necessary to your answers. And yes, some of the questions are vague and difficult to answer precisely - let's do our best and remember the objective is to provide practical answers that would be useful to a manager/developer choosing a dynamic language, not to debate terms in an academic sense. 1) Can a developer extend the language by adding new keywords? My answer to this is no, short of recompiling the underlying parser -- with the new AST engine of 2.5, am I wrong? Can Jython or IronPython do it? 2) How large is the on disk runtime that has to be installed to run programs written in this language? I don't run either Jython or IronPython -- can anyone who does provide an answer? And yes, it is a bit unclear as in whether it includes all of Java and .NET or just the delta above those. Go with the delta, it's smaller. 3) What applications are available to developers using this language that support application lifecycle for requirements, design, development, build, and test? 4) How many new major and minor features were added in the last release? Let's assume they mean the last major release. 5) How many committers to the core does the project have relative to the scope of the project? Hmm, how to measure the "scope of the project"? Lines of code in cPython, IronPython and Jython? A rough guess of the class/module count? 6) How many bug reports have there been for the latest release? 7) How many email postings have there been (including developer and user lists) in the past six months? 8) How much communication occurs within the community? Besides email postings, what other forms of communication occur within the community? What forms of collaboration are used? 9) How complete is the language and framework support for Web service standards? Does the language support Core Web Services? Does the language supports Web Service Security standards? Does the language supports Web Services Management standards? Does the language provides Registry and Metadata support? Does the language support Web service Process and Delivery Control standards? Does the language support Web services Transactions and Packaging standards? Not being a web services kind of developer, I need some help here. 10) How many companies offer end user support for the product? Is there one company primarily identified with the project that provides end customer support? Definitely not a single company, like Sun for Java, at least for cPython and Jython. Is Microsoft the primary company providing end-user support for IronPython though? Many of these companies may be members of the PSF, so speak up. 11) How many systems integrators use the language in application development? Considering Python is a secret weapon for many companies, this will be hard. But can anyone provide some anecdotal information? Thank you very much for your time and effort, Jeff Rush Advocacy Coordinator From ctrachte at gmail.com Thu May 10 16:42:01 2007 From: ctrachte at gmail.com (Carl Trachte) Date: Thu, 10 May 2007 07:42:01 -0700 Subject: [IronPython] A Few Questions for the Python Community re Survey Response In-Reply-To: <46431CAE.1010709@taupro.com> References: <46431CAE.1010709@taupro.com> Message-ID: <426ada670705100742g14e3fd8dib5e56b4faa44eed0@mail.gmail.com> Jeff, I don't know if PyPy "counts" as an official Python implementation, but I'm pretty sure you can add new keywords in PyPy (I'm not a PyPy expert, or even a dilettante, but I've seen this capability demo'd at PYCON). Carl T. 1) Can a developer extend the language by adding new keywords? > > My answer to this is no, short of recompiling the underlying parser -- > with > the new AST engine of 2.5, am I wrong? Can Jython or IronPython do it? > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Maly at microsoft.com Thu May 10 18:44:50 2007 From: Martin.Maly at microsoft.com (Martin Maly) Date: Thu, 10 May 2007 09:44:50 -0700 Subject: [IronPython] SyntaxError: yield in more than one try blocks In-Reply-To: <4642F698.6060804@defuze.org> References: <4642F698.6060804@defuze.org> Message-ID: Yes, this is currently a an unfortunate limitation of our compiler. Martin -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch Sent: Thursday, May 10, 2007 3:40 AM To: Discussion of IronPython Subject: [IronPython] SyntaxError: yield in more than one try blocks sylvain at 4[WebApp]$ mono bin/ipy.exe IronPython 1.1 (1.1) on .NET 2.0.50727.42 def test(): try: yield 1 except: try: yield 2 except: pass if __name__ == '__main__': for _ in test(): print _ Will produce: sylvain at 4[WebApp]$ mono bin/ipy.exe -X:Python25 testyield.py Traceback (most recent call last): SyntaxError: yield in more than one try blocks (testyield.py, line 6) It does work fine with CPython 2.5 - Sylvain _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From ctrachte at gmail.com Thu May 10 19:17:02 2007 From: ctrachte at gmail.com (Carl Trachte) Date: Thu, 10 May 2007 10:17:02 -0700 Subject: [IronPython] A Few Questions for the Python Community re Survey Response In-Reply-To: <426ada670705100742g14e3fd8dib5e56b4faa44eed0@mail.gmail.com> References: <46431CAE.1010709@taupro.com> <426ada670705100742g14e3fd8dib5e56b4faa44eed0@mail.gmail.com> Message-ID: <426ada670705101017u1f69498ds8879e83b8540c485@mail.gmail.com> Sorry, my bad. I didn't see the "limited to cPython, IronPython, and Jython thing until Carl K.'s e-mail. Nevermind. On 5/10/07, Carl Trachte wrote: > > Jeff, > I don't know if PyPy "counts" as an official Python implementation, but > I'm pretty sure you can add new keywords in PyPy (I'm not a PyPy expert, or > even a dilettante, but I've seen this capability demo'd at PYCON). > Carl T. > > > 1) Can a developer extend the language by adding new keywords? > > > > My answer to this is no, short of recompiling the underlying parser -- > > with > > the new AST engine of 2.5, am I wrong? Can Jython or IronPython do it? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sh at defuze.org Thu May 10 19:30:59 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Thu, 10 May 2007 18:30:59 +0100 Subject: [IronPython] SyntaxError: yield in more than one try blocks In-Reply-To: References: <4642F698.6060804@defuze.org> Message-ID: <464356D3.3070702@defuze.org> I assume you are looking at a solution in the future :) Martin Maly wrote: > Yes, this is currently a an unfortunate limitation of our compiler. > > Martin > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch > Sent: Thursday, May 10, 2007 3:40 AM > To: Discussion of IronPython > Subject: [IronPython] SyntaxError: yield in more than one try blocks > > sylvain at 4[WebApp]$ mono bin/ipy.exe > IronPython 1.1 (1.1) on .NET 2.0.50727.42 > > def test(): > try: > yield 1 > except: > try: > yield 2 > except: > pass > > if __name__ == '__main__': > for _ in test(): > print _ > > > Will produce: > sylvain at 4[WebApp]$ mono bin/ipy.exe -X:Python25 testyield.py > Traceback (most recent call last): > SyntaxError: yield in more than one try blocks (testyield.py, line 6) > > > It does work fine with CPython 2.5 > > - 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 Martin.Maly at microsoft.com Thu May 10 19:33:34 2007 From: Martin.Maly at microsoft.com (Martin Maly) Date: Thu, 10 May 2007 10:33:34 -0700 Subject: [IronPython] SyntaxError: yield in more than one try blocks In-Reply-To: <464356D3.3070702@defuze.org> References: <4642F698.6060804@defuze.org> <464356D3.3070702@defuze.org> Message-ID: Absolutely! -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch Sent: Thursday, May 10, 2007 10:31 AM To: Discussion of IronPython Subject: Re: [IronPython] SyntaxError: yield in more than one try blocks I assume you are looking at a solution in the future :) Martin Maly wrote: > Yes, this is currently a an unfortunate limitation of our compiler. > > Martin > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch > Sent: Thursday, May 10, 2007 3:40 AM > To: Discussion of IronPython > Subject: [IronPython] SyntaxError: yield in more than one try blocks > > sylvain at 4[WebApp]$ mono bin/ipy.exe > IronPython 1.1 (1.1) on .NET 2.0.50727.42 > > def test(): > try: > yield 1 > except: > try: > yield 2 > except: > pass > > if __name__ == '__main__': > for _ in test(): > print _ > > > Will produce: > sylvain at 4[WebApp]$ mono bin/ipy.exe -X:Python25 testyield.py > Traceback (most recent call last): > SyntaxError: yield in more than one try blocks (testyield.py, line 6) > > > It does work fine with CPython 2.5 > > - 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 sh at defuze.org Thu May 10 20:07:55 2007 From: sh at defuze.org (Sylvain Hellegouarch) Date: Thu, 10 May 2007 19:07:55 +0100 Subject: [IronPython] SyntaxError: yield in more than one try blocks In-Reply-To: References: <4642F698.6060804@defuze.org> <464356D3.3070702@defuze.org> Message-ID: <46435F7B.4050901@defuze.org> Great :) Thanks, Martin Maly wrote: > Absolutely! > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch > Sent: Thursday, May 10, 2007 10:31 AM > To: Discussion of IronPython > Subject: Re: [IronPython] SyntaxError: yield in more than one try blocks > > I assume you are looking at a solution in the future :) > > Martin Maly wrote: >> Yes, this is currently a an unfortunate limitation of our compiler. >> >> Martin >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch >> Sent: Thursday, May 10, 2007 3:40 AM >> To: Discussion of IronPython >> Subject: [IronPython] SyntaxError: yield in more than one try blocks >> >> sylvain at 4[WebApp]$ mono bin/ipy.exe >> IronPython 1.1 (1.1) on .NET 2.0.50727.42 >> >> def test(): >> try: >> yield 1 >> except: >> try: >> yield 2 >> except: >> pass >> >> if __name__ == '__main__': >> for _ in test(): >> print _ >> >> >> Will produce: >> sylvain at 4[WebApp]$ mono bin/ipy.exe -X:Python25 testyield.py >> Traceback (most recent call last): >> SyntaxError: yield in more than one try blocks (testyield.py, line 6) >> >> >> It does work fine with CPython 2.5 >> >> - 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 sanxiyn at gmail.com Fri May 11 13:40:54 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 11 May 2007 20:40:54 +0900 Subject: [IronPython] IronPython 2.0 Alpha 1 on Mono In-Reply-To: <5b0248170705020322x4663ac42t997a2f63f1d363be@mail.gmail.com> References: <5b0248170705020322x4663ac42t997a2f63f1d363be@mail.gmail.com> Message-ID: <5b0248170705110440m3c8cf2d8n19eb2287aac01a42@mail.gmail.com> 2007/5/2, Sanghyeon Seo : > Here's my first try on building IronPython 2.0 Alpha 1 on Mono: > https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/2.0a1/ > (snip) Mono revision later than 77232 compiles IronPython 2.0 Alpha 1 without any modifications besides makefile patch. So, in short, you can forget about this. :-) I will briefly look at what I can do to make it work with Mono 1.2.2.1. This is a personal convinience, as it is the version that shipped with the Debian stable release. -- Seo Sanghyeon From xmlhacker at gmail.com Fri May 11 19:17:45 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Fri, 11 May 2007 11:17:45 -0600 Subject: [IronPython] IronPython 2.0 Alpha 1 on Mono In-Reply-To: <5b0248170705110440m3c8cf2d8n19eb2287aac01a42@mail.gmail.com> References: <5b0248170705020322x4663ac42t997a2f63f1d363be@mail.gmail.com> <5b0248170705110440m3c8cf2d8n19eb2287aac01a42@mail.gmail.com> Message-ID: Do I understand correctly: IP 2.0, and therefore the DLR, will now compile on Mono, and as such, it is now possible to begin the process of trying to break it? This would be fantastic! :D (/me is building Mono from SVN, hopes to have successfully built IP 2.0 soon thereafter...) On 5/11/07, Sanghyeon Seo wrote: > > 2007/5/2, Sanghyeon Seo : > > Here's my first try on building IronPython 2.0 Alpha 1 on Mono: > > https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/2.0a1/ > > (snip) > > Mono revision later than 77232 compiles IronPython 2.0 Alpha 1 without > any modifications besides makefile patch. > > So, in short, you can forget about this. :-) > > I will briefly look at what I can do to make it work with Mono > 1.2.2.1. This is a personal convinience, as it is the version that > shipped with the Debian stable release. > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jim.Hugunin at microsoft.com Sat May 12 03:13:00 2007 From: Jim.Hugunin at microsoft.com (Jim Hugunin) Date: Fri, 11 May 2007 18:13:00 -0700 Subject: [IronPython] A Few Questions for the Python Community re Survey Response In-Reply-To: <46431CAE.1010709@taupro.com> References: <46431CAE.1010709@taupro.com> Message-ID: My answers are inline for your first four questions. I don't have time to fill out the rest right now, but I thought that you'd rather have a partial answer than to wait on something more thorough that may or may not come. Thanks - Jim 1) Can a developer extend the language by adding new keywords? My answer to this is no, short of recompiling the underlying parser -- with the new AST engine of 2.5, am I wrong? Can Jython or IronPython do it? JJH> IronPython can't do this, short of building a new parser. 2) How large is the on disk runtime that has to be installed to run programs written in this language? I don't run either Jython or IronPython -- can anyone who does provide an answer? And yes, it is a bit unclear as in whether it includes all of Java and .NET or just the delta above those. Go with the delta, it's smaller. JJH> IronPython-1.1 is roughly 1.4MB total in 3 dlls - and on Windows Vista, this is the FULL install size since .NET is already there. Note that for IronPython the standard .py Python libraries are not included "in the box", so you may or may not want to add some version of that number to this. 3) What applications are available to developers using this language that support application lifecycle for requirements, design, development, build, and test? JJH> IronPython has some integration with the VS tools suite, but it's very limited today. From xmlhacker at gmail.com Sat May 12 07:48:38 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Fri, 11 May 2007 23:48:38 -0600 Subject: [IronPython] IronPython 2.0 Alpha 1 on Mono In-Reply-To: References: <5b0248170705020322x4663ac42t997a2f63f1d363be@mail.gmail.com> <5b0248170705110440m3c8cf2d8n19eb2287aac01a42@mail.gmail.com> Message-ID: BTW... for those keeping score, as Seo proclaimed, IP 2.0A1 will now successfully build on Mono (SVN r77275). I have my doubts the stacktrace will be all that useful to anyone, but you never know, so for what its worth, [mdavid at domU-12-31-37-00-03-10 Debug]$ mono ipy.exe > Stacktrace: > > at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(bool) <0x00004> > at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(bool) <0xfffffff> > at System.Reflection.Assembly.GetExportedTypes () <0x0000c> > at Microsoft.Scripting.ReflectedPackage.LoadTypesFromAssembly ( > System.Reflection.Assembly) <0x00071> > at Microsoft.Scripting.TopReflectedPackage.LoadAssembly ( > System.Reflection.Assembly) <0x0003d> > at Microsoft.Scripting.ClrModule.AddReference ( > System.Reflection.Assembly) <0x0004a> > at Microsoft.Scripting.ClrModule.AddReference (object) <0x00035> > at Microsoft.Scripting.ClrModule.AddReference (object[]) <0x0003a> > at IronPython.Runtime.SystemState.InitializeBuiltins () <0x00075> > at IronPython.Runtime.SystemState..ctor ( > Microsoft.Scripting.Hosting.ScriptEngine,IronPython.Runtime.Importer) > <0x0005d> > at IronPython.Hosting.PythonEngine..ctor ( > IronPython.Hosting.PythonLanguageProvider,IronPython.PythonEngineOptions) > <0x00089> > at IronPython.Hosting.PythonEngine.<>c__AnonymousMethod0 ( > IronPython.Hosting.PythonLanguageProvider,IronPython.PythonEngineOptions) > <0x0001f> > at (wrapper delegate-invoke) > System.MulticastDelegate.invoke_PythonEngine_PythonLanguageProvider_PythonEngineOptions( > IronPython.Hosting.PythonLanguageProvider,IronPython.PythonEngineOptions) > <0xffffffff> > at Microsoft.Scripting.Hosting.SingletonEngineFactory`3.GetInstance ( > IronPython.Hosting.PythonLanguageProvider,IronPython.PythonEngineOptions) > <0x000a8> > at IronPython.Hosting.PythonLanguageProvider.GetEngine ( > Microsoft.Scripting.EngineOptions) <0x0005a> > at > Microsoft.Scripting.Hosting.LanguageProvider.Microsoft.Scripting.Hosting.IL > anguageProvider.GetEngine (Microsoft.Scripting.EngineOptions) <0x0000e> > at Microsoft.Scripting.Hosting.ConsoleHost.RunCommandLine ( > Microsoft.Scripting.OptionsParser) <0x00089> > at Microsoft.Scripting.Hosting.ConsoleHost.ExecuteInternal () <0x0026d> > at Microsoft.Scripting.Hosting.ConsoleHost.Execute () <0x0009b> > at Microsoft.Scripting.Hosting.ConsoleHost.Run (string[]) <0x00143> > at PythonConsoleHost.Main (string[]) <0x00025> > at (wrapper runtime-invoke) System.Object.runtime_invoke_int_string[] > (object,intptr,intptr,intptr) <0xffffffff> > > Native stacktrace: > > mono [0x8143e83] > mono [0x81300b6] > [0xbfffe440] > mono [0x80dc1f0] > mono(mono_class_get_full+0x99) [0x80dbb55] > mono(mono_class_get+0x13) [0x80dbcd3] > mono [0x8094d8b] > mono [0x8095089] > [0xb6f4596c] > [0xb6f45925] > [0xb6f45832] > [0xb6f453a6] > [0xb6f47843] > [0xb6f4771e] > [0xb6f47683] > [0xb7015fde] > [0xb7014f1e] > [0xb70147b2] > [0xb7014358] > [0xb7014305] > [0xb7014131] > [0xb701402b] > [0xb7012b5f] > [0xb7012802] > [0xb7012066] > [0xb7011d0c] > [0xb7495784] > [0xb74951e6] > [0xb7495074] > mono(mono_runtime_exec_main+0x151) [0x808b2e1] > mono(mono_runtime_run_main+0x1f0) [0x808b584] > mono(mono_main+0xf27) [0x8058f9b] > mono [0x8057c0f] > /lib/tls/libc.so.6(__libc_start_main+0xcf) [0xb7d7c23f] > mono [0x8057b71] > > ================================================================= > Got a SIGSEGV while executing native code. This usually indicates > a fatal error in the mono runtime or one of the native libraries > used by your application. > ================================================================= > > Aborted > On 5/11/07, M. David Peterson wrote: > > Do I understand correctly: IP 2.0, and therefore the DLR, will now compile > on Mono, and as such, it is now possible to begin the process of trying to > break it? This would be fantastic! :D > > (/me is building Mono from SVN, hopes to have successfully built IP 2.0soon thereafter...) > > On 5/11/07, Sanghyeon Seo wrote: > > > > 2007/5/2, Sanghyeon Seo : > > > Here's my first try on building IronPython 2.0 Alpha 1 on Mono: > > > https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/2.0a1/ > > > (snip) > > > > Mono revision later than 77232 compiles IronPython 2.0 Alpha 1 without > > any modifications besides makefile patch. > > > > So, in short, you can forget about this. :-) > > > > I will briefly look at what I can do to make it work with Mono > > 1.2.2.1. This is a personal convinience, as it is the version that > > shipped with the Debian stable release. > > > > -- > > Seo Sanghyeon > > _______________________________________________ > > users mailing list > > users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > -- > /M:D > > M. David Peterson > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | > http://dev.aol.com/blog/3155 -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From drew at astro.pas.rochester.edu Sat May 12 17:01:20 2007 From: drew at astro.pas.rochester.edu (drew moore) Date: Sat, 12 May 2007 11:01:20 -0400 Subject: [IronPython] Immutable value types, again In-Reply-To: <463E42F2.6070100@astro.pas.rochester.edu> References: <463BC0C7.2040606@voidspace.org.uk> <463E42F2.6070100@astro.pas.rochester.edu> Message-ID: <4645D6C0.4030902@astro.pas.rochester.edu> No comments on mutable value types? I hope my post wasn't too trollish. I expected *somebody* to respond. I figured if I was struggling with it, other people had to be as well, so I felt obligated to speak up. Upside: * Nobody else seems to be having issues with the immutable value types decision. Perhaps most interfaces follow "the guidelines" and most users don't run across this one. * Nobody clued me in on something I could have done short of writing some C# code. I expected some kind soul to say something like "you fool, you just need to cast it to a ref type and then you can mutate it all you want. When you need the val type, just cast it back. Didn't you read the tutorial??" I don't do much IronPython or .NET stuff so I'm a bit of a noob there. I did read the tutorials, but I might have missed something. Just curious: does IronRuby have a similar situation? Did they make the same decision? (not that I'm thinking of switching to Ruby. Ruby's a great language I hear, but I'm too much of a Python fanatic to switch. ;-) cheers Drew From xmlhacker at gmail.com Sat May 12 18:17:19 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sat, 12 May 2007 10:17:19 -0600 Subject: [IronPython] Immutable value types, again In-Reply-To: <4645D6C0.4030902@astro.pas.rochester.edu> References: <463BC0C7.2040606@voidspace.org.uk> <463E42F2.6070100@astro.pas.rochester.edu> <4645D6C0.4030902@astro.pas.rochester.edu> Message-ID: > I expected *somebody* to respond. Okay, I'm up for the task, Me: "you fool, you just need to cast it to a ref type and then you can mutate it all you want. When you need the val type, just cast it back. Didn't you read the tutorial??" Of course, I have no idea if this is the right answer, but I would hate for you to think that nobody's listening and nobody cares. That said, it's possible it might be one or the other. But I doubt much it's both at the same time. ;-) On a serious note, there are a few threads that come to mind, though I am not immediatelly finding either of them. That said, try > http://lists.ironpython.com/pipermail/users-ironpython.com/2006-November/004134.html < and then take a look @ > http://lists.ironpython.com/pipermail/users-ironpython.com/2007-January/004432.html < and see if either of these might help lead you down the path to finding the right answer. When I have a few extra moments I'll try and dig deeper and find something a bit more useful. -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 From fireonyoursleeve at hotmail.com Mon May 14 00:32:57 2007 From: fireonyoursleeve at hotmail.com (Aaron Leiby) Date: Sun, 13 May 2007 15:32:57 -0700 Subject: [IronPython] Orcas integration? References: <463BC0C7.2040606@voidspace.org.uk><463E42F2.6070100@astro.pas.rochester.edu><4645D6C0.4030902@astro.pas.rochester.edu> Message-ID: Has any progress on the IP integration with VS been released since the v4.0 VS SDK? (http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx) I'm really digging the IronPython 2.0 (DLR) integration with Silverlight, but finding it much more difficult to prototype with than C# due to lack of IDE support. Maybe others can describe setups they've had success with; Notepad simply ain't cutting it. Aaron I made a simple bouncy ball here: http://aleiby.blogspot.com/2007/05/silverlight.html From fireonyoursleeve at hotmail.com Mon May 14 00:45:59 2007 From: fireonyoursleeve at hotmail.com (Aaron Leiby) Date: Sun, 13 May 2007 15:45:59 -0700 Subject: [IronPython] Immutable value types, again References: <463BC0C7.2040606@voidspace.org.uk><463E42F2.6070100@astro.pas.rochester.edu> <4645D6C0.4030902@astro.pas.rochester.edu> Message-ID: This was the very first issue I ran into using IronPython fwiw. http://lists.ironpython.com/htdig.cgi/users-ironpython.com/2007-March/004626.html I wound up falling back to writing C# code for those situations. They were almost always too slow to be doing in IP to start with. I agree it's a very easy trap to fall into. I would prefer it *just worked*, but can (loosely) understand the arguments. Aaron ----- Original Message ----- From: "drew moore" To: "Discussion of IronPython" Sent: Saturday, May 12, 2007 8:01 AM Subject: Re: [IronPython] Immutable value types, again > No comments on mutable value types? > I hope my post wasn't too trollish. I expected *somebody* to respond. > I figured if I was struggling with it, other people had to be as well, > so I felt obligated to speak up. > > Upside: > > * Nobody else seems to be having issues with the immutable value types > decision. Perhaps most interfaces follow "the guidelines" and most users > don't run across this one. > > * Nobody clued me in on something I could have done short of writing > some C# code. I expected some kind soul to say something like "you fool, > you just need to cast it to a ref type and then you can mutate it all > you want. When you need the val type, just cast it back. Didn't you read > the tutorial??" I don't do much IronPython or .NET stuff so I'm a bit of > a noob there. I did read the tutorials, but I might have missed something. > > Just curious: does IronRuby have a similar situation? Did they make the > same decision? (not that I'm thinking of switching to Ruby. Ruby's a > great language I hear, but I'm too much of a Python fanatic to switch. ;-) > > cheers > > Drew > > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From xmlhacker at gmail.com Mon May 14 00:56:14 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sun, 13 May 2007 16:56:14 -0600 Subject: [IronPython] IronPython 2.0 Alpha 1 on Mono In-Reply-To: References: <5b0248170705020322x4663ac42t997a2f63f1d363be@mail.gmail.com> <5b0248170705110440m3c8cf2d8n19eb2287aac01a42@mail.gmail.com> Message-ID: Getting closer, [mdavid at domU-12-31-37-00-03-10 Src]$ mono -V Mono JIT compiler version 1.2.4 (/trunk/ r77328) Copyright (C) 2002-2007 Novell, Inc and Contributors. www.mono-project.com TLS: __thread GC: Included Boehm (with typed GC) SIGSEGV: normal Architecture: x86 Disabled: none [mdavid at domU-12-31-37-00-03-10 Src]$ mono ../Bin/Debug/ipy.exe Unhandled Exception: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. at System.Collections.Generic.Dictionary`2[System.String,System.Type].get_Item (System.String ) [0x00000] at IronPython.Runtime.SystemState.InitializeBuiltins () [0x00000] at IronPython.Runtime.SystemState..ctor ( Microsoft.Scripting.Hosting.ScriptEngine engine, IronPython.Runtime.Importerimporter) [0x00000] at IronPython.Hosting.PythonEngine..ctor ( IronPython.Hosting.PythonLanguageProvider provider, IronPython.PythonEngineOptions engineOptions) [0x00000] at IronPython.Hosting.PythonEngine.<>c__AnonymousMethod0[PythonLanguageProvider,PythonEngineOptions,PythonEngine] (IronPython.Hosting.PythonLanguageProvider provider, IronPython.PythonEngineOptions options) [0x00000] at (wrapper delegate-invoke) System.MulticastDelegate:invoke_PythonEngine_PythonLanguageProvider_PythonEngineOptions( IronPython.Hosting.PythonLanguageProvider,IronPython.PythonEngineOptions) at Microsoft.Scripting.Hosting.SingletonEngineFactory`3[ IronPython.Hosting.PythonEngine,IronPython.PythonEngineOptions, IronPython.Hosting.PythonLanguageProvider].GetInstance ( IronPython.Hosting.PythonLanguageProvider , IronPython.PythonEngineOptions ) [0x00000] at IronPython.Hosting.PythonLanguageProvider.GetEngine ( Microsoft.Scripting.EngineOptions options) [0x00000] at Microsoft.Scripting.Hosting.LanguageProvider.Microsoft.Scripting.Hosting.ILanguageProvider.GetEngine( Microsoft.Scripting.EngineOptions options) [0x00000] at Microsoft.Scripting.Hosting.ConsoleHost.RunCommandLine ( Microsoft.Scripting.OptionsParser optionsParser) [0x00000] at Microsoft.Scripting.Hosting.ConsoleHost.ExecuteInternal () [0x00000] at Microsoft.Scripting.Hosting.ConsoleHost.Execute () [0x00000] at Microsoft.Scripting.Hosting.ConsoleHost.Run (System.String[] args) [0x00000] at PythonConsoleHost.Main (System.String[] args) [0x00000] On 5/11/07, M. David Peterson wrote: > > BTW... for those keeping score, as Seo proclaimed, IP 2.0A1 will now > successfully build on Mono (SVN r77275). I have my doubts the stacktrace > will be all that useful to anyone, but you never know, so for what its > worth, > > [mdavid at domU-12-31-37-00-03-10 Debug]$ mono ipy.exe > > Stacktrace: > > > > at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(bool) <0x00004> > > at (wrapper managed-to-native) System.Reflection.Assembly.GetTypes(bool) <0xfffffff> > > at System.Reflection.Assembly.GetExportedTypes () <0x0000c> > > at Microsoft.Scripting.ReflectedPackage.LoadTypesFromAssembly ( > > System.Reflection.Assembly) <0x00071> > > at Microsoft.Scripting.TopReflectedPackage.LoadAssembly ( > > System.Reflection.Assembly) <0x0003d> > > at Microsoft.Scripting.ClrModule.AddReference ( > > System.Reflection.Assembly) <0x0004a> > > at Microsoft.Scripting.ClrModule.AddReference (object) <0x00035> > > at Microsoft.Scripting.ClrModule.AddReference (object[]) <0x0003a> > > at IronPython.Runtime.SystemState.InitializeBuiltins () <0x00075> > > at IronPython.Runtime.SystemState..ctor ( > > Microsoft.Scripting.Hosting.ScriptEngine,IronPython.Runtime.Importer) > > <0x0005d> > > at IronPython.Hosting.PythonEngine..ctor ( > > IronPython.Hosting.PythonLanguageProvider,IronPython.PythonEngineOptions) > > <0x00089> > > at IronPython.Hosting.PythonEngine.<>c__AnonymousMethod0 ( > > IronPython.Hosting.PythonLanguageProvider,IronPython.PythonEngineOptions) <0x0001f> > > at (wrapper delegate-invoke) > > System.MulticastDelegate.invoke_PythonEngine_PythonLanguageProvider_PythonEngineOptions( > > IronPython.Hosting.PythonLanguageProvider,IronPython.PythonEngineOptions) > > <0xffffffff> > > at Microsoft.Scripting.Hosting.SingletonEngineFactory`3.GetInstance ( > > IronPython.Hosting.PythonLanguageProvider,IronPython.PythonEngineOptions) > > <0x000a8> > > at IronPython.Hosting.PythonLanguageProvider.GetEngine ( > > Microsoft.Scripting.EngineOptions) <0x0005a> > > at Microsoft.Scripting.Hosting.LanguageProvider.Microsoft.Scripting.Hosting.IL > > > > anguageProvider.GetEngine (Microsoft.Scripting.EngineOptions) <0x0000e> > > at Microsoft.Scripting.Hosting.ConsoleHost.RunCommandLine ( > > Microsoft.Scripting.OptionsParser) <0x00089> > > at Microsoft.Scripting.Hosting.ConsoleHost.ExecuteInternal () > > <0x0026d> > > at Microsoft.Scripting.Hosting.ConsoleHost.Execute () <0x0009b> > > at Microsoft.Scripting.Hosting.ConsoleHost.Run (string[]) <0x00143> > > at PythonConsoleHost.Main (string[]) <0x00025> > > at (wrapper runtime-invoke) System.Object.runtime_invoke_int_string[] > > (object,intptr,intptr,intptr) <0xffffffff> > > > > Native stacktrace: > > > > mono [0x8143e83] > > mono [0x81300b6] > > [0xbfffe440] > > mono [0x80dc1f0] > > mono(mono_class_get_full+0x99) [0x80dbb55] > > mono(mono_class_get+0x13) [0x80dbcd3] > > mono [0x8094d8b] > > mono [0x8095089] > > [0xb6f4596c] > > [0xb6f45925] > > [0xb6f45832] > > [0xb6f453a6] > > [0xb6f47843] > > [0xb6f4771e] > > [0xb6f47683] > > [0xb7015fde] > > [0xb7014f1e] > > [0xb70147b2] > > [0xb7014358] > > [0xb7014305] > > [0xb7014131] > > [0xb701402b] > > [0xb7012b5f] > > [0xb7012802] > > [0xb7012066] > > [0xb7011d0c] > > [0xb7495784] > > [0xb74951e6] > > [0xb7495074] > > mono(mono_runtime_exec_main+0x151) [0x808b2e1] > > mono(mono_runtime_run_main+0x1f0) [0x808b584] > > mono(mono_main+0xf27) [0x8058f9b] > > mono [0x8057c0f] > > /lib/tls/libc.so.6(__libc_start_main+0xcf) [0xb7d7c23f] > > mono [0x8057b71] > > > > ================================================================= > > Got a SIGSEGV while executing native code. This usually indicates > > a fatal error in the mono runtime or one of the native libraries > > used by your application. > > ================================================================= > > > > Aborted > > > > On 5/11/07, M. David Peterson < xmlhacker at gmail.com> wrote: > > > > Do I understand correctly: IP 2.0, and therefore the DLR, will now > > compile on Mono, and as such, it is now possible to begin the process of > > trying to break it? This would be fantastic! :D > > > > (/me is building Mono from SVN, hopes to have successfully built IP 2.0soon thereafter...) > > > > On 5/11/07, Sanghyeon Seo < sanxiyn at gmail.com> wrote: > > > > > > 2007/5/2, Sanghyeon Seo : > > > > Here's my first try on building IronPython 2.0 Alpha 1 on Mono: > > > > https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/patches/2.0a1/ > > > > (snip) > > > > > > Mono revision later than 77232 compiles IronPython 2.0 Alpha 1 without > > > any modifications besides makefile patch. > > > > > > So, in short, you can forget about this. :-) > > > > > > I will briefly look at what I can do to make it work with Mono > > > 1.2.2.1. This is a personal convinience, as it is the version that > > > shipped with the Debian stable release. > > > > > > -- > > > Seo Sanghyeon > > > _______________________________________________ > > > users mailing list > > > users at lists.ironpython.com > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > > > > > > -- > > /M:D > > > > M. David Peterson > > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | > > http://dev.aol.com/blog/3155 > > > > > -- > /M:D > > M. David Peterson > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | > http://dev.aol.com/blog/3155 > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmlhacker at gmail.com Mon May 14 01:04:49 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sun, 13 May 2007 17:04:49 -0600 Subject: [IronPython] Orcas integration? In-Reply-To: References: <463BC0C7.2040606@voidspace.org.uk> <463E42F2.6070100@astro.pas.rochester.edu> <4645D6C0.4030902@astro.pas.rochester.edu> Message-ID: On 5/13/07, Aaron Leiby wrote: > > Has any progress on the IP integration with VS been released since the > v4.0 > VS SDK? > (http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx) You mean something other than the "Microsoft Silverlight Tools Alpha for Visual Studio codename "Orcas" Beta 1? http://www.microsoft.com/downloads/details.aspx?familyid=6C2B309B-8F2D-44A5-B04F-836F0D4EC1C4&displaylang=en -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmlhacker at gmail.com Mon May 14 01:11:13 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sun, 13 May 2007 17:11:13 -0600 Subject: [IronPython] Orcas integration? In-Reply-To: References: <463BC0C7.2040606@voidspace.org.uk> <463E42F2.6070100@astro.pas.rochester.edu> <4645D6C0.4030902@astro.pas.rochester.edu> Message-ID: You should also try out the Expression Blend 2 May Preview, http://www.microsoft.com/downloads/details.aspx?familyid=88925FC5-B395-4911-9A02-9FDD80CEA564&displaylang=en As per the overview, We are pleased to present our very first preview of Microsoft Expression > Blend 2. The Expression Blend 2 May Preview allows you to create Microsoft > Silverlight-based applications. Additionally, you can export content from > Microsoft(r) Expression(r) Design in a format that can be used in > Silverlight-based applications that you create in Expression Blend 2 May > Preview. You may also find Microsoft(r) Expression(r) Media Encoder Preview to > be helpful when working with video, Silverlight, > and Expression Blend 2 May Preview. NOTE: While the above doesn't explicitly state Silverlight 1.1 Alpha, it does provide direct support for it. On 5/13/07, M. David Peterson wrote: > > On 5/13/07, Aaron Leiby wrote: > > > > Has any progress on the IP integration with VS been released since the > > v4.0 > > VS SDK? > > (http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx ) > > > You mean something other than the "Microsoft Silverlight Tools Alpha for > Visual Studio codename "Orcas" Beta 1? > > http://www.microsoft.com/downloads/details.aspx?familyid=6C2B309B-8F2D-44A5-B04F-836F0D4EC1C4&displaylang=en > > > -- > /M:D > > M. David Peterson > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | > http://dev.aol.com/blog/3155 -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmlhacker at gmail.com Mon May 14 01:13:57 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sun, 13 May 2007 17:13:57 -0600 Subject: [IronPython] Orcas integration? In-Reply-To: References: <463BC0C7.2040606@voidspace.org.uk> <463E42F2.6070100@astro.pas.rochester.edu> <4645D6C0.4030902@astro.pas.rochester.edu> Message-ID: On 5/13/07, M. David Peterson wrote: > > On 5/13/07, Aaron Leiby wrote: > > > > Has any progress on the IP integration with VS been released since the > > v4.0 > > VS SDK? > > (http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx ) > > > You mean something other than the "Microsoft Silverlight Tools Alpha for > Visual Studio codename "Orcas" Beta 1? > Doh! Yeah, okay, you said "IronPython". If not mistaken, there is no enhanced support for IronPython inside of Orcas. http://www.microsoft.com/downloads/details.aspx?familyid=6C2B309B-8F2D-44A5-B04F-836F0D4EC1C4&displaylang=en > > > -- > /M:D > > M. David Peterson > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | > http://dev.aol.com/blog/3155 -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fireonyoursleeve at hotmail.com Mon May 14 01:17:04 2007 From: fireonyoursleeve at hotmail.com (Aaron Leiby) Date: Sun, 13 May 2007 16:17:04 -0700 Subject: [IronPython] Orcas integration? References: <463BC0C7.2040606@voidspace.org.uk><463E42F2.6070100@astro.pas.rochester.edu><4645D6C0.4030902@astro.pas.rochester.edu> Message-ID: I think so. I have that installed and don't see anything IronPython related in Orcas. According to the Overview, it adds support for VB, C#, XAML and Expression Blend integration. This is great for C# development, which I've been toying with, but was hoping to play with the IronPython bits some more. (I may have worded that poorly in the initial email looking back.) After sending out that email, I discovered the VSX team has their Orcas SDK April 2007 CTP up at http://www.vsipmembers.com. I'm downloading that now. Hopefully it has all the same IP VS integration goodness that was in the v4.0 release for 2005, updated for Orcas. Aaron ----- Original Message ----- From: M. David Peterson To: Discussion of IronPython Sent: Sunday, May 13, 2007 4:04 PM Subject: Re: [IronPython] Orcas integration? On 5/13/07, Aaron Leiby wrote: Has any progress on the IP integration with VS been released since the v4.0 VS SDK? (http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx ) You mean something other than the "Microsoft Silverlight Tools Alpha for Visual Studio codename "Orcas" Beta 1? http://www.microsoft.com/downloads/details.aspx?familyid=6C2B309B-8F2D-44A5-B04F-836F0D4EC1C4&displaylang=en -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 ------------------------------------------------------------------------------ _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidjensen at usa.net Mon May 14 01:48:34 2007 From: davidjensen at usa.net (David Jensen) Date: Sun, 13 May 2007 19:48:34 -0400 Subject: [IronPython] IronPython on Windows Mobile 6 Message-ID: <058LemXvI8276S30.1179100114@cmsweb30.cms.usa.net> Does IronPython run on Windows Mobile 6? David Jensen From xmlhacker at gmail.com Mon May 14 04:13:14 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sun, 13 May 2007 20:13:14 -0600 Subject: [IronPython] IronPython on Windows Mobile 6 In-Reply-To: <058LemXvI8276S30.1179100114@cmsweb30.cms.usa.net> References: <058LemXvI8276S30.1179100114@cmsweb30.cms.usa.net> Message-ID: I was about to point you @ http://lists.ironpython.com/htdig.cgi/users-ironpython.com/2007-March/004614.htmlbut then realized that it was you that Dino responded to regarding Windows Mobile 5. So then I guess the question would be does Windows Mobile 6 provide support for Reflection.Emit. I think the answer is no, but I can't be certain. Anybody else know the answer? On 5/13/07, David Jensen wrote: > > Does IronPython run on Windows Mobile 6? > > > David Jensen > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmlhacker at gmail.com Mon May 14 05:02:09 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sun, 13 May 2007 21:02:09 -0600 Subject: [IronPython] Orcas integration? In-Reply-To: References: <463BC0C7.2040606@voidspace.org.uk> <463E42F2.6070100@astro.pas.rochester.edu> <4645D6C0.4030902@astro.pas.rochester.edu> Message-ID: On 5/13/07, Aaron Leiby wrote: > After sending out that email, I discovered the VSX team has their Orcas SDK > April 2007 CTP up at http://www.vsipmembers.com. I'm downloading that now. Nice find! Downloading it myself now... > Hopefully it has all the same IP VS integration goodness that was in the > v4.0 release for 2005, updated for Orcas. Any luck? -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 From LThompson at ixiacom.com Mon May 14 18:47:06 2007 From: LThompson at ixiacom.com (Lyle Thompson) Date: Mon, 14 May 2007 09:47:06 -0700 Subject: [IronPython] Issue overridding __call__ In-Reply-To: References: Message-ID: <897A9E9DE9919A42B110869B344311F4102BD0@IXCA-EXCHANGE.ixiacom.com> I think I may have found a bug in IP1.1. I have a class hierarchy of callable objects, shown below. The problem appears to be that Ipy confuses __call__ with __init__. I have found that if I use super for line 19, then the problem moves to line 20, for which I have no workaround. Any ideas? Thanks, Lyle class Callable1(object): def __init__(self): print "calling Callable1.__init__" def __call__(self): print "calling Callable1.__call__" class Callable2(object): def __init__(self): print "calling Callable2.__init__" def __call__(self): print "calling Callable2.__call__" class Callable1And2(Callable1, Callable2): def __call__(self): Callable1.__call__(self) # <--- line 19 Callable2.__call__(self) c = Callable1And2() c() # <---- line 23 This gives me the following error: Traceback (most recent call last): File , line 0, in ##10 File , line 0, in __import__##4 File d:\p4\ixweb3\3.30\Client\callable.py, line 23, in Initialize File d:\p4\ixweb3\3.30\Client\callable.py, line 19, in __call__ TypeError: __init__() takes exactly 1 argument (2 given) From fuzzyman at voidspace.org.uk Mon May 14 22:08:25 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 14 May 2007 21:08:25 +0100 Subject: [IronPython] Article on a Simple HTTP Server with IronPython Message-ID: <4648C1B9.4090002@voidspace.org.uk> Hello all, I've written an article on creating a simple webserver using the .NET ``HttpListener`` class. * `A Simple HTTP Server with IronPython `_ This article also touches on text encoding, asynchronous callbacks, URI and XHTML escaping, and creating a simple Windows Forms dialog. If you are new to .NET, this is a valuable tour of parts of the .NET 'standard library'. Feedback (and bug reports!) welcome. Michael Foord From dinov at exchange.microsoft.com Mon May 14 22:53:23 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 14 May 2007 13:53:23 -0700 Subject: [IronPython] Issue overridding __call__ In-Reply-To: <897A9E9DE9919A42B110869B344311F4102BD0@IXCA-EXCHANGE.ixiacom.com> References: <897A9E9DE9919A42B110869B344311F4102BD0@IXCA-EXCHANGE.ixiacom.com> Message-ID: <7AD436E4270DD54A94238001769C222790AD439EEE@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Thanks for the bug report. I believe this is the same as bug #7594 (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7594). We've already fixed that in the v2.0 branch (where types are behaving quite differently than they were in v1.x). Could you vote on the issue - that way we can keep track of its effect and potentially back port it in the future. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Lyle Thompson Sent: Monday, May 14, 2007 9:47 AM To: users at lists.ironpython.com Subject: [IronPython] Issue overridding __call__ I think I may have found a bug in IP1.1. I have a class hierarchy of callable objects, shown below. The problem appears to be that Ipy confuses __call__ with __init__. I have found that if I use super for line 19, then the problem moves to line 20, for which I have no workaround. Any ideas? Thanks, Lyle class Callable1(object): def __init__(self): print "calling Callable1.__init__" def __call__(self): print "calling Callable1.__call__" class Callable2(object): def __init__(self): print "calling Callable2.__init__" def __call__(self): print "calling Callable2.__call__" class Callable1And2(Callable1, Callable2): def __call__(self): Callable1.__call__(self) # <--- line 19 Callable2.__call__(self) c = Callable1And2() c() # <---- line 23 This gives me the following error: Traceback (most recent call last): File , line 0, in ##10 File , line 0, in __import__##4 File d:\p4\ixweb3\3.30\Client\callable.py, line 23, in Initialize File d:\p4\ixweb3\3.30\Client\callable.py, line 19, in __call__ TypeError: __init__() takes exactly 1 argument (2 given) _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fireonyoursleeve at hotmail.com Tue May 15 01:15:50 2007 From: fireonyoursleeve at hotmail.com (Aaron Leiby) Date: Mon, 14 May 2007 16:15:50 -0700 Subject: [IronPython] Orcas integration? References: <463BC0C7.2040606@voidspace.org.uk><463E42F2.6070100@astro.pas.rochester.edu><4645D6C0.4030902@astro.pas.rochester.edu> Message-ID: > Any luck? I didn't get to spend too much time on this yesterday, but all the IronPython Visual Studio integration seems to have been ported over intact. It's still using IP1.1 though, and I didn't dig far enough to see what it would take to update it to use IP2.0. Also, the Silverlight project wizards create a C# vproj which builds a dll and then launches your app in IE. There aren't yet any project wizards for setting up a similar vproj for IronPython. Of course the whole point of the VS SDK is so we can add this stuff ourselves, but I'd rather focus on using the tools at this point instead of extending them. You can setup a C# Silverlight project and simply remove all the .cs files, add your own .py files and switch the XAML over to using that instead: Two things keeping this from being useful for me at this time: 1) IE pops up the ActiveX "are you sure" warning every time you launch for debugging (this doesn't happen when just using the default C# codebehind). 2) The debugger doesn't catch exceptions thrown by IronPython (like it does when launching an IronPython project) - instead the script just halts (though other bits of the Silverlight app continue running as though nothing happened). The first one is just annoying, but the second one killed me when I wasted an hour due to a missing 'global' declaration. x = 10 def foo(): global x # <-- I was missing this x = -x Definitely a step in the right direction, but still a little early to be working with it at this point it seems. If anyone knows workarounds to the above mentioned issues, please share. Aaron ----- Original Message ----- From: "M. David Peterson" To: "Discussion of IronPython" Sent: Sunday, May 13, 2007 8:02 PM Subject: Re: [IronPython] Orcas integration? > On 5/13/07, Aaron Leiby wrote: > >> After sending out that email, I discovered the VSX team has their Orcas >> SDK >> April 2007 CTP up at http://www.vsipmembers.com. I'm downloading that >> now. > > Nice find! Downloading it myself now... > >> Hopefully it has all the same IP VS integration goodness that was in the >> v4.0 release for 2005, updated for Orcas. > > Any luck? > > -- > /M:D > > M. David Peterson > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | > http://dev.aol.com/blog/3155 > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dinov at exchange.microsoft.com Tue May 15 03:40:11 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 14 May 2007 18:40:11 -0700 Subject: [IronPython] Orcas integration? In-Reply-To: References: <463BC0C7.2040606@voidspace.org.uk><463E42F2.6070100@astro.pas.rochester.edu><4645D6C0.4030902@astro.pas.rochester.edu> , Message-ID: <7AD436E4270DD54A94238001769C222790ACF7A48A@DF-GRTDANE-MSG.exchange.corp.microsoft.com> FYI getting this to work w/ v2.0 is probably no small amount of work. We've temporarily removed several features from v2.0 (such as CodeDom and the static type compiler) which were used by the VS SDK integration to varying degrees. The AST has also significantly changed which probably means the language service that targetted v1.x and shipped w/ the VS SDK is probably quite broken too. We are talking to the VS SDK team and trying to figure out what version their next release will target, when we can get those various features back into 2.0, etc... Unfortunately we don't have any sort of ETA yet. On the other issues: #1) You probably need the Mark of the Web in the .html file. This will tell IE that the file that's local on your machine is to be treated as being in the internet zone. A quick search for mark of the web should get you what you need. #2) There's an outer most exception handler and you might have VS setup to catch unhandled exceptions. Try disabling that in the exceptions menu. If that doesn't do it try disabling Just My Code and it should start catching all exceptions. ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Aaron Leiby [fireonyoursleeve at hotmail.com] Sent: Monday, May 14, 2007 4:15 PM To: Discussion of IronPython Subject: Re: [IronPython] Orcas integration? > Any luck? I didn't get to spend too much time on this yesterday, but all the IronPython Visual Studio integration seems to have been ported over intact. It's still using IP1.1 though, and I didn't dig far enough to see what it would take to update it to use IP2.0. Also, the Silverlight project wizards create a C# vproj which builds a dll and then launches your app in IE. There aren't yet any project wizards for setting up a similar vproj for IronPython. Of course the whole point of the VS SDK is so we can add this stuff ourselves, but I'd rather focus on using the tools at this point instead of extending them. You can setup a C# Silverlight project and simply remove all the .cs files, add your own .py files and switch the XAML over to using that instead: Two things keeping this from being useful for me at this time: 1) IE pops up the ActiveX "are you sure" warning every time you launch for debugging (this doesn't happen when just using the default C# codebehind). 2) The debugger doesn't catch exceptions thrown by IronPython (like it does when launching an IronPython project) - instead the script just halts (though other bits of the Silverlight app continue running as though nothing happened). The first one is just annoying, but the second one killed me when I wasted an hour due to a missing 'global' declaration. x = 10 def foo(): global x # <-- I was missing this x = -x Definitely a step in the right direction, but still a little early to be working with it at this point it seems. If anyone knows workarounds to the above mentioned issues, please share. Aaron ----- Original Message ----- From: "M. David Peterson" To: "Discussion of IronPython" Sent: Sunday, May 13, 2007 8:02 PM Subject: Re: [IronPython] Orcas integration? > On 5/13/07, Aaron Leiby wrote: > >> After sending out that email, I discovered the VSX team has their Orcas >> SDK >> April 2007 CTP up at http://www.vsipmembers.com. I'm downloading that >> now. > > Nice find! Downloading it myself now... > >> Hopefully it has all the same IP VS integration goodness that was in the >> v4.0 release for 2005, updated for Orcas. > > Any luck? > > -- > /M:D > > M. David Peterson > http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | > http://dev.aol.com/blog/3155 > _______________________________________________ > 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 fireonyoursleeve at hotmail.com Tue May 15 07:48:23 2007 From: fireonyoursleeve at hotmail.com (Aaron Leiby) Date: Mon, 14 May 2007 22:48:23 -0700 Subject: [IronPython] Orcas integration? References: <463BC0C7.2040606@voidspace.org.uk><463E42F2.6070100@astro.pas.rochester.edu><4645D6C0.4030902@astro.pas.rochester.edu>, <7AD436E4270DD54A94238001769C222790ACF7A48A@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: Good call on both counts. For the exceptions, under Debug -> Exceptions... unchecking 'User-unhandled' for all Common Language Runtime Exceptions, and checking 'Thrown' instead enables breaking on stuff like divide by zero. For the missing 'global' I had to add Microsoft.Scripting.UnboundLocalException (same checkbox settings). I imagine there will be more, but they're easy enough to add as they show up in the debug output window as unhandled. Thanks. Aaron ----- Original Message ----- From: "Dino Viehland" To: "Discussion of IronPython" Sent: Monday, May 14, 2007 6:40 PM Subject: Re: [IronPython] Orcas integration? > FYI getting this to work w/ v2.0 is probably no small amount of work. > We've temporarily removed several features from v2.0 (such as CodeDom and > the static type compiler) which were used by the VS SDK integration to > varying degrees. The AST has also significantly changed which probably > means the language service that targetted v1.x and shipped w/ the VS SDK > is probably quite broken too. > > We are talking to the VS SDK team and trying to figure out what version > their next release will target, when we can get those various features > back into 2.0, etc... Unfortunately we don't have any sort of ETA yet. > > On the other issues: > #1) You probably need the Mark of the Web in the .html file. This will > tell IE that the file that's local on your machine is to be treated as > being in the internet zone. A quick search for mark of the web should get > you what you need. > > #2) There's an outer most exception handler and you might have VS setup > to catch unhandled exceptions. Try disabling that in the exceptions menu. > If that doesn't do it try disabling Just My Code and it should start > catching all exceptions. > > > ________________________________________ > From: users-bounces at lists.ironpython.com > [users-bounces at lists.ironpython.com] On Behalf Of Aaron Leiby > [fireonyoursleeve at hotmail.com] > Sent: Monday, May 14, 2007 4:15 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Orcas integration? > >> Any luck? > > I didn't get to spend too much time on this yesterday, but all the > IronPython Visual Studio integration seems to have been ported over > intact. > It's still using IP1.1 though, and I didn't dig far enough to see what it > would take to update it to use IP2.0. Also, the Silverlight project > wizards > create a C# vproj which builds a dll and then launches your app in IE. > There aren't yet any project wizards for setting up a similar vproj for > IronPython. Of course the whole point of the VS SDK is so we can add this > stuff ourselves, but I'd rather focus on using the tools at this point > instead of extending them. > > You can setup a C# Silverlight project and simply remove all the .cs > files, > add your own .py files and switch the XAML over to using that instead: > > > Two things keeping this from being useful for me at this time: > > 1) IE pops up the ActiveX "are you sure" warning every time you launch for > debugging (this doesn't happen when just using the default C# codebehind). > > 2) The debugger doesn't catch exceptions thrown by IronPython (like it > does > when launching an IronPython project) - instead the script just halts > (though other bits of the Silverlight app continue running as though > nothing > happened). > > The first one is just annoying, but the second one killed me when I wasted > an hour due to a missing 'global' declaration. > > x = 10 > def foo(): > global x # <-- I was missing this > x = -x > > Definitely a step in the right direction, but still a little early to be > working with it at this point it seems. > > If anyone knows workarounds to the above mentioned issues, please share. > > > Aaron > > ----- Original Message ----- > From: "M. David Peterson" > To: "Discussion of IronPython" > Sent: Sunday, May 13, 2007 8:02 PM > Subject: Re: [IronPython] Orcas integration? > >> On 5/13/07, Aaron Leiby wrote: >> >>> After sending out that email, I discovered the VSX team has their Orcas >>> SDK >>> April 2007 CTP up at http://www.vsipmembers.com. I'm downloading that >>> now. >> >> Nice find! Downloading it myself now... >> >>> Hopefully it has all the same IP VS integration goodness that was in the >>> v4.0 release for 2005, updated for Orcas. >> >> Any luck? >> >> -- >> /M:D >> >> M. David Peterson >> http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | >> http://dev.aol.com/blog/3155 >> _______________________________________________ >> 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 Tue May 15 18:17:05 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 16 May 2007 01:17:05 +0900 Subject: [IronPython] Bug in 2.0a1 SystemState.InitializeBuiltins Message-ID: <5b0248170705150917x11df1723ib88a977b61da7363@mail.gmail.com> I hope the bug is obvious once pointed out. InitializeBuiltins method contains a code to replace built-in nt module with posix module when Platform is PlatformID.Unix. But this is done *before* IronPython.Modules is loaded! As a result, KeyNotFoundException is raised. Clearly, this won't happen on Windows. -- Seo Sanghyeon From gbraad at gmail.com Tue May 15 18:55:35 2007 From: gbraad at gmail.com (Gerard Braad Jr.) Date: Tue, 15 May 2007 16:55:35 -0000 Subject: [IronPython] dispatch console command Message-ID: <1179248135.984138.188410@p77g2000hsh.googlegroups.com> Hello, in a 'previous' release of IronPython I was able to use IronPython.Hosting.PythonEngine.ConsoleCommandDispatcher = DispatchConsoleCommand to dispatch a console command to my own function, which invokes a command to a Form. In the newer 2.0a1 release (based on DLR) I was not able to find this functionality. Is this now part of a script/ enginemanager? any help would be appreciated. greets, Gerard From dinov at exchange.microsoft.com Tue May 15 21:49:33 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 15 May 2007 12:49:33 -0700 Subject: [IronPython] dispatch console command In-Reply-To: <1179248135.984138.188410@p77g2000hsh.googlegroups.com> References: <1179248135.984138.188410@p77g2000hsh.googlegroups.com> Message-ID: <7AD436E4270DD54A94238001769C222790AD43A200@DF-GRTDANE-MSG.exchange.corp.microsoft.com> This has moved to ScriptDomainManager.CurrentManager.GetCommandDispatcher/SetCommandDispatcher. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Gerard Braad Jr. Sent: Tuesday, May 15, 2007 9:56 AM To: users at lists.ironpython.com Subject: [IronPython] dispatch console command Hello, in a 'previous' release of IronPython I was able to use IronPython.Hosting.PythonEngine.ConsoleCommandDispatcher = DispatchConsoleCommand to dispatch a console command to my own function, which invokes a command to a Form. In the newer 2.0a1 release (based on DLR) I was not able to find this functionality. Is this now part of a script/ enginemanager? any help would be appreciated. greets, Gerard _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From xmlhacker at gmail.com Wed May 16 02:31:22 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Tue, 15 May 2007 18:31:22 -0600 Subject: [IronPython] Orcas integration? In-Reply-To: References: <463BC0C7.2040606@voidspace.org.uk> <4645D6C0.4030902@astro.pas.rochester.edu> <7AD436E4270DD54A94238001769C222790ACF7A48A@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: *TONS* of great information here. Thanks to both of you (Dino and Aaron) for providing it! On 5/14/07, Aaron Leiby wrote: > Good call on both counts. For the exceptions, under Debug -> Exceptions... > unchecking 'User-unhandled' for all Common Language Runtime Exceptions, and > checking 'Thrown' instead enables breaking on stuff like divide by zero. > For the missing 'global' I had to add > Microsoft.Scripting.UnboundLocalException (same checkbox settings). I > imagine there will be more, but they're easy enough to add as they show up > in the debug output window as unhandled. Thanks. > > Aaron > > ----- Original Message ----- > From: "Dino Viehland" > To: "Discussion of IronPython" > Sent: Monday, May 14, 2007 6:40 PM > Subject: Re: [IronPython] Orcas integration? > > > FYI getting this to work w/ v2.0 is probably no small amount of work. > > We've temporarily removed several features from v2.0 (such as CodeDom and > > the static type compiler) which were used by the VS SDK integration to > > varying degrees. The AST has also significantly changed which probably > > means the language service that targetted v1.x and shipped w/ the VS SDK > > is probably quite broken too. > > > > We are talking to the VS SDK team and trying to figure out what version > > their next release will target, when we can get those various features > > back into 2.0, etc... Unfortunately we don't have any sort of ETA yet. > > > > On the other issues: > > #1) You probably need the Mark of the Web in the .html file. This will > > tell IE that the file that's local on your machine is to be treated as > > being in the internet zone. A quick search for mark of the web should get > > you what you need. > > > > #2) There's an outer most exception handler and you might have VS setup > > to catch unhandled exceptions. Try disabling that in the exceptions menu. > > If that doesn't do it try disabling Just My Code and it should start > > catching all exceptions. > > > > > > ________________________________________ > > From: users-bounces at lists.ironpython.com > > [users-bounces at lists.ironpython.com] On Behalf Of Aaron Leiby > > [fireonyoursleeve at hotmail.com] > > Sent: Monday, May 14, 2007 4:15 PM > > To: Discussion of IronPython > > Subject: Re: [IronPython] Orcas integration? > > > >> Any luck? > > > > I didn't get to spend too much time on this yesterday, but all the > > IronPython Visual Studio integration seems to have been ported over > > intact. > > It's still using IP1.1 though, and I didn't dig far enough to see what it > > would take to update it to use IP2.0. Also, the Silverlight project > > wizards > > create a C# vproj which builds a dll and then launches your app in IE. > > There aren't yet any project wizards for setting up a similar vproj for > > IronPython. Of course the whole point of the VS SDK is so we can add this > > stuff ourselves, but I'd rather focus on using the tools at this point > > instead of extending them. > > > > You can setup a C# Silverlight project and simply remove all the .cs > > files, > > add your own .py files and switch the XAML over to using that instead: > > > > > > Two things keeping this from being useful for me at this time: > > > > 1) IE pops up the ActiveX "are you sure" warning every time you launch for > > debugging (this doesn't happen when just using the default C# codebehind). > > > > 2) The debugger doesn't catch exceptions thrown by IronPython (like it > > does > > when launching an IronPython project) - instead the script just halts > > (though other bits of the Silverlight app continue running as though > > nothing > > happened). > > > > The first one is just annoying, but the second one killed me when I wasted > > an hour due to a missing 'global' declaration. > > > > x = 10 > > def foo(): > > global x # <-- I was missing this > > x = -x > > > > Definitely a step in the right direction, but still a little early to be > > working with it at this point it seems. > > > > If anyone knows workarounds to the above mentioned issues, please share. > > > > > > Aaron > > > > ----- Original Message ----- > > From: "M. David Peterson" > > To: "Discussion of IronPython" > > Sent: Sunday, May 13, 2007 8:02 PM > > Subject: Re: [IronPython] Orcas integration? > > > >> On 5/13/07, Aaron Leiby wrote: > >> > >>> After sending out that email, I discovered the VSX team has their Orcas > >>> SDK > >>> April 2007 CTP up at http://www.vsipmembers.com. I'm downloading that > >>> now. > >> > >> Nice find! Downloading it myself now... > >> > >>> Hopefully it has all the same IP VS integration goodness that was in the > >>> v4.0 release for 2005, updated for Orcas. > >> > >> Any luck? > >> > >> -- > >> /M:D > >> > >> M. David Peterson > >> http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | > >> http://dev.aol.com/blog/3155 > >> _______________________________________________ > >> 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 > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 From kfarmer at thuban.org Wed May 16 06:41:18 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Tue, 15 May 2007 21:41:18 -0700 Subject: [IronPython] IronPython on Windows Mobile 6 In-Reply-To: References: <058LemXvI8276S30.1179100114@cmsweb30.cms.usa.net> Message-ID: How about IronPython 2.0, on Silverlight (DLR), on WM6? (I actually don?t know, but I think it?d be fun?) From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of M. David Peterson Sent: Sunday, May 13, 2007 7:13 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython on Windows Mobile 6 I was about to point you @ http://lists.ironpython.com/htdig.cgi/users-ironpython.com/2007-March/004614.html but then realized that it was you that Dino responded to regarding Windows Mobile 5. So then I guess the question would be does Windows Mobile 6 provide support for Reflection.Emit. I think the answer is no, but I can't be certain. Anybody else know the answer? On 5/13/07, David Jensen < davidjensen at usa.net > wrote: Does IronPython run on Windows Mobile 6? David Jensen _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbraad at gmail.com Wed May 16 10:24:00 2007 From: gbraad at gmail.com (Gerard Braad Jr.) Date: Wed, 16 May 2007 08:24:00 -0000 Subject: [IronPython] dispatch console command In-Reply-To: <7AD436E4270DD54A94238001769C222790AD43A200@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <1179248135.984138.188410@p77g2000hsh.googlegroups.com> <7AD436E4270DD54A94238001769C222790AD43A200@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <1179303840.223476.268940@p77g2000hsh.googlegroups.com> It is not possible for me to use the same structure in an easy way. Since it seems AttributeError: attribute 'SetCommandDispatcher' of 'ScriptDomainManager' object is read-only Can the ScriptDomainManager also handle configuration files on a per assembly base? On May 15, 9:49 pm, Dino Viehland wrote: > This has moved to ScriptDomainManager.CurrentManager.GetCommandDispatcher/SetCommandDispatcher. From xmlhacker at gmail.com Wed May 16 10:30:33 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Wed, 16 May 2007 02:30:33 -0600 Subject: [IronPython] Update: IP 2.0A1/DLR on Mono Message-ID: http://www.oreillynet.com/xml/blog/2007/05/monodlr_hello_dynamic_language.html -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From drew at astro.pas.rochester.edu Wed May 16 14:40:35 2007 From: drew at astro.pas.rochester.edu (drew moore) Date: Wed, 16 May 2007 08:40:35 -0400 Subject: [IronPython] Immutable value types, again In-Reply-To: References: <463BC0C7.2040606@voidspace.org.uk> <463E42F2.6070100@astro.pas.rochester.edu> <4645D6C0.4030902@astro.pas.rochester.edu> Message-ID: <464AFBC3.4070508@astro.pas.rochester.edu> M. David Peterson wrote: > Okay, I'm up for the task, > > Me: "you fool, you just need to cast it to a ref type and then you can > mutate it all > you want. When you need the val type, just cast it back. Didn't you read > the tutorial??" > Hee hee. Wish I'd thought of that. I was poking around for some sort of way out in this direction, originally. Perhaps this console session might help illustrate where I got stuck. >>> model = k3d.CModelClass() >>> sphere = model.CreateSphere(1.0) >>> pos = sphere.position >>> pos.X, pos.Y, pos.Z (0.0, 0.0, 0.0) >>> pos.X = 3.0 Traceback (most recent call last): File , line 0, in ##50 ValueError: Attempt to update field 'X' on value type 'tVector'; value type fields cannot be directly modified >>> pos.__class__ >>> tVector = pos.__class__ >>> pos = tVector(1,2,3) Traceback (most recent call last): File , line 0, in ##32 File , line 0, in DefaultNew##18 TypeError: default __new__ does not take parameters >>> pos = tVector((1,2,3)) Traceback (most recent call last): File , line 0, in ##33 File , line 0, in DefaultNew##34 TypeError: default __new__ does not take parameters >>> pos = tVector(X=1,Y=2,Z=3) Traceback (most recent call last): File , line 0, in ##35 File , line 0, in DefaultNewClsKW##39 ValueError: Attempt to update field 'X' on value type 'tVector'; value type fiel ds cannot be directly modified Dang. That last one *almost* worked? (can you make just the KW constructor work, guys?) >>> dir(pos) ['Equals', 'Finalize', 'GetHashCode', 'GetType', 'MakeDynamicType', 'MemberwiseC lone', 'Reduce', 'ReferenceEquals', 'ToString', 'X', 'Y', 'Z', '__class__', '__d oc__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__re pr__', '__str__'] I have no instance methods for getting and setting, so I appear to be out of luck. Value types are apparently always sealed, so I can't even subclass it in C# to add them. I need to write a proxy. I have no idea if MakeDynamicType does what I imagine it might do. I'm pretty sure it won't, but it's the most promising thing I can see on my object. Easier to ask forgiveness!! >>> pos.MakeDynamicType() Traceback (most recent call last): File , line 0, in ##52 TypeError: MakeDynamicType() takes exactly 0 arguments (1 given) >>> pos.MakeDynamicType >>> tVector.MakeDynamicType() Traceback (most recent call last): File , line 0, in ##55 TypeError: descriptor 'MakeDynamicType' of 'object' needs an argument >>> tVector.MakeDynamicType(pos) Traceback (most recent call last): File , line 0, in ##56 TypeError: MakeDynamicType() takes exactly 0 arguments (1 given) >>> I'm shooting in the dark here. In any event, the last two errors seem to contradict each other, don't they? I'm guessing that http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython&title=Value%20Types has my answer: > This renders value types ?mostly? immutable; updates are still > possible via instance methods on the value type itself. I have no instance methods on this struct. Therefore, I can't mutate it in *any* way from IronPython, even though mutating it is some of the most trivial code imaginable in C#. I'd be ready to crawl under a rock if I was trying to sell IronPython to some C# programmers and I had to explain this one! > This is where you come in: we?d like to know whether these changes > impact your scenarios and if so what facilities we could provide in > order to address the situation. We?d also appreciate knowing that this > change doesn?t impact you at all so we can get a clearer view of the > big picture. I *do* think the "draconian" immutable value types decision was the right (ok, safe) one to make *at the time.* Without *some* facility for creating new instances of value types from pure IronPython, (like a working KW args constructor) I'm not sure it is a good long-term solution. Clearer big picture: After one year, we have learned that not many people are having trouble with this. That means, perhaps, that not many people are using value types from IronPython? (good interfaces avoid them!) That means, perhaps, if value types *were* mutable in IronPython, not many people would notice *that* either? Hey, here's another try. "It's Python. Its a dynamic language. We *have* to write unit tests. The bug we are trying to prevent will not stay in our code for very long, because our unit tests will catch it." ;-) cheers Drew From sanxiyn at gmail.com Wed May 16 16:15:07 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 16 May 2007 23:15:07 +0900 Subject: [IronPython] Update: IP 2.0A1/DLR on Mono In-Reply-To: References: Message-ID: <5b0248170705160715x7fcbf9f6tfc43f5197972b172@mail.gmail.com> The final summary: Get Mono from SVN with revision later than 77476. It has fixed all compiler bugs and runtime bugs impacting IronPython 2.0 Alpha 1 as far as I can tell. -- Seo Sanghyeon From jeff at taupro.com Wed May 16 16:45:59 2007 From: jeff at taupro.com (Jeff Rush) Date: Wed, 16 May 2007 09:45:59 -0500 Subject: [IronPython] Forrester Survey Asks: Python and Garbage Collection Features Message-ID: <464B1927.2010509@taupro.com> In working on the Forrester Research survey, I've come across two questions to which I don't know the answer, for Jython and IronPython. I would like those two language implementations to be clearly represented in the survey, not just cPython, and therefore would appreciate help with brief 1 paragraph answers. I assume their garbage collection capabilities are tied to that underlying .NET and the JVM, but I'm not technically familiar with those, nor if there are additional capabilities we should highlight beyond what cPython provides. Memory management/ Garbage Collection ===================================== F30: Advanced Garbage Collection -------------------------------- "Does the language support advanced garbage collection algorithms?" cPython: uses reference counting, with cycle detection and breaking it also has weak references (refs to objects that don't keep it from being collected); GC can be queried for objects still in existence; a collection cycle can be initiated explicitly; can detect and explicitly break uncollectables (cycles of isolated objects) Jython: ??? uses mark-and-sweep ??? IronPython: ??? F31: Tunable Garbage Collection ------------------------------- "Can a developer tune the garbage collection capabilities?" cPython: the GC can be turned off/on to avoid disruptions to critical timing, the collection frequency/threshold can be adjusted, Jython: ??? IronPython: ??? Thanks! -Jeff Python Advocacy Coordinator From xmlhacker at gmail.com Wed May 16 16:45:38 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Wed, 16 May 2007 08:45:38 -0600 Subject: [IronPython] Update: IP 2.0A1/DLR on Mono In-Reply-To: <5b0248170705160715x7fcbf9f6tfc43f5197972b172@mail.gmail.com> References: <5b0248170705160715x7fcbf9f6tfc43f5197972b172@mail.gmail.com> Message-ID: As far as I can tell too :D (post linked to originally has been updated appropriately) On 5/16/07, Sanghyeon Seo wrote: > > The final summary: > > Get Mono from SVN with revision later than 77476. It has fixed all > compiler bugs and runtime bugs impacting IronPython 2.0 Alpha 1 as far > as I can tell. > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Wed May 16 17:41:47 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 16 May 2007 08:41:47 -0700 Subject: [IronPython] dispatch console command In-Reply-To: <1179303840.223476.268940@p77g2000hsh.googlegroups.com> References: <1179248135.984138.188410@p77g2000hsh.googlegroups.com> <7AD436E4270DD54A94238001769C222790AD43A200@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <1179303840.223476.268940@p77g2000hsh.googlegroups.com> Message-ID: <7AD436E4270DD54A94238001769C222790AD43A41E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Instead of just setting it you'll need to call it w/ the object you had - it should be a fairly simple tweak. It will then return the previous command dispatcher giving a nice chaining which wasn't possible before. What do you mean by on a per assembly base? As in having multiple config files? -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Gerard Braad Jr. Sent: Wednesday, May 16, 2007 1:24 AM To: users at lists.ironpython.com Subject: Re: [IronPython] dispatch console command It is not possible for me to use the same structure in an easy way. Since it seems AttributeError: attribute 'SetCommandDispatcher' of 'ScriptDomainManager' object is read-only Can the ScriptDomainManager also handle configuration files on a per assembly base? On May 15, 9:49 pm, Dino Viehland wrote: > This has moved to ScriptDomainManager.CurrentManager.GetCommandDispatcher/SetCommandDispatcher. _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Wed May 16 17:42:42 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 16 May 2007 08:42:42 -0700 Subject: [IronPython] Bug in 2.0a1 SystemState.InitializeBuiltins In-Reply-To: <5b0248170705150917x11df1723ib88a977b61da7363@mail.gmail.com> References: <5b0248170705150917x11df1723ib88a977b61da7363@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222790AD43A41F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Definitely a bug, I've got an idea on a better way to fit it then just change when the we change the name. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Tuesday, May 15, 2007 9:17 AM To: Discussion of IronPython Subject: [IronPython] Bug in 2.0a1 SystemState.InitializeBuiltins I hope the bug is obvious once pointed out. InitializeBuiltins method contains a code to replace built-in nt module with posix module when Platform is PlatformID.Unix. But this is done *before* IronPython.Modules is loaded! As a result, KeyNotFoundException is raised. Clearly, this won't happen on Windows. -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From unittesting at gmail.com Thu May 17 17:45:59 2007 From: unittesting at gmail.com (Bish Bosh) Date: Thu, 17 May 2007 11:45:59 -0400 Subject: [IronPython] Referring to Python types in Xaml Message-ID: What is the mechanism for making types in the Python domain available to the WPF type system for use in a Xaml file? In the code below I am refering to the Python class to do some formatting but would have the same problem if I was trying to create an instance of a Python class in the Xaml file. Any ideas? I'm pretty sure I'm missing something simple but fundamental. As usual. In Python file I have a type: class FancyData(ObservableCollection[str]): pass The collection to be displayed I am adding as an application resource: app.Resources.Add('collection', FancyData()) So it can be bound to as expected in the Xaml: In Xaml file I would like to refer to the type to do some formatting: ... I get the error: File data1.py, line 108, in Initialize File , line 0, in _stub_##77 File data1.py, line 26, in LoadXaml File , line 0, in _stub_##87 File PresentationFramework, line unknown, in Load File PresentationFramework, line unknown, in XmlTreeBuildDefault File PresentationFramework, line unknown, in Parse File PresentationFramework, line unknown, in ParseFragment File PresentationFramework, line unknown, in _Parse File PresentationFramework, line unknown, in ReadXaml File PresentationFramework, line unknown, in Read SystemError: Type reference cannot find public type named 'FancyData'. From dinov at exchange.microsoft.com Thu May 17 18:24:37 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 17 May 2007 09:24:37 -0700 Subject: [IronPython] Referring to Python types in Xaml In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C222791BC5DD30D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> We don't generate a type that can be easily consumed from static languages. Can you use an interface in the DataTemplate line, eg: If so then you could declare an interface in C# (or find an existing one which has what you want) and inherit & implement the interface in Python. Then the interface will be the bridge between the static & dynamic worlds. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Bish Bosh Sent: Thursday, May 17, 2007 8:46 AM To: users at lists.ironpython.com Subject: [IronPython] Referring to Python types in Xaml What is the mechanism for making types in the Python domain available to the WPF type system for use in a Xaml file? In the code below I am refering to the Python class to do some formatting but would have the same problem if I was trying to create an instance of a Python class in the Xaml file. Any ideas? I'm pretty sure I'm missing something simple but fundamental. As usual. In Python file I have a type: class FancyData(ObservableCollection[str]): pass The collection to be displayed I am adding as an application resource: app.Resources.Add('collection', FancyData()) So it can be bound to as expected in the Xaml: In Xaml file I would like to refer to the type to do some formatting: ... I get the error: File data1.py, line 108, in Initialize File , line 0, in _stub_##77 File data1.py, line 26, in LoadXaml File , line 0, in _stub_##87 File PresentationFramework, line unknown, in Load File PresentationFramework, line unknown, in XmlTreeBuildDefault File PresentationFramework, line unknown, in Parse File PresentationFramework, line unknown, in ParseFragment File PresentationFramework, line unknown, in _Parse File PresentationFramework, line unknown, in ReadXaml File PresentationFramework, line unknown, in Read SystemError: Type reference cannot find public type named 'FancyData'. _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From unittesting at gmail.com Thu May 17 19:41:41 2007 From: unittesting at gmail.com (Bish Bosh) Date: Thu, 17 May 2007 13:41:41 -0400 Subject: [IronPython] Referring to Python types in Xaml In-Reply-To: <7AD436E4270DD54A94238001769C222791BC5DD30D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222791BC5DD30D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: Interesting. My intention is not to have any C# in the projects so cooking my own type by that method is out. I guess people are just not using IP as a one for one replacement for C# as I had hoped to. In the two cases I talked about in post I guess I have workarounds. For creating instances I can create them in Python code and add them to the Resource database for use in the Xaml. For templating I can create a typeless data template and simply refer to this when I display the collection rather than have the system find this template automatically by type. No biggie really for the simple apps I'm doing, the benefits of using Python and Xaml outweigh these wrinkles. I wonder if the DLR is addressing these sort of typing issues? Up to now I'm a little unclear what those chaps are up to. Thanks for your prompt answer. On 5/17/07, Dino Viehland wrote: > We don't generate a type that can be easily consumed from static languages. Can you use an interface in the DataTemplate line, eg: > > > > If so then you could declare an interface in C# (or find an existing one which has what you want) and inherit & implement the interface in Python. Then the interface will be the bridge between the static & dynamic worlds. > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Bish Bosh > Sent: Thursday, May 17, 2007 8:46 AM > To: users at lists.ironpython.com > Subject: [IronPython] Referring to Python types in Xaml > > What is the mechanism for making types in the Python domain available > to the WPF type system for use in a Xaml file? > > In the code below I am refering to the Python class to do some > formatting but would have the same problem if I was trying to create > an instance of a Python class in the Xaml file. Any ideas? I'm pretty > sure I'm missing something simple but fundamental. As usual. > > In Python file I have a type: > > class FancyData(ObservableCollection[str]): > pass > > The collection to be displayed I am adding as an application resource: > > app.Resources.Add('collection', FancyData()) > > So it can be bound to as expected in the Xaml: > > > > In Xaml file I would like to refer to the type to do some formatting: > > > > ... > > I get the error: > > File data1.py, line 108, in Initialize > File , line 0, in _stub_##77 > File data1.py, line 26, in LoadXaml > File , line 0, in _stub_##87 > File PresentationFramework, line unknown, in Load > File PresentationFramework, line unknown, in XmlTreeBuildDefault > File PresentationFramework, line unknown, in Parse > File PresentationFramework, line unknown, in ParseFragment > File PresentationFramework, line unknown, in _Parse > File PresentationFramework, line unknown, in ReadXaml > File PresentationFramework, line unknown, in Read > SystemError: Type reference cannot find public type named 'FancyData'. > _______________________________________________ From sanxiyn at gmail.com Thu May 17 19:41:46 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 18 May 2007 02:41:46 +0900 Subject: [IronPython] pystone results for 1.0 vs 2.0a1 on various runtimes Message-ID: <5b0248170705171041k6f2e80e8l5dfeb53ee5f02d29@mail.gmail.com> I believe some of you may be interested in these results. In the video of DLR talk at MIX07, "the one and only powerpoint slide that actually contains content" shows pystone numbers for various versions of CPython and IronPython. (Seek to 37:50.) IronPython 1.0: 90K IronPython 2.0a1: 101K I assume these numbers are on Microsoft .NET included in Windows Vista. (Is it Orcas instead? Maybe that's why this differs from WinFX result below?) It shows 12% gain in pystone numbers. (I also note that IronPython 1.0 and 1.1 are virtually identical in terms of performance.) However, I can't reproduce this performance gain on Mono. The best of 3 results on my laptop gives 32% loss: IronPython 1.0: 31K IronPython 2.0a1: 21K Confused, I ran pystone on Windows XP PC to verify. Again, the results didn't match the slide (21% loss): IronPython 1.1: 68K IronPython 2.0a1: 54K I messaged M. David Peterson about the issue, and he gave me the results on Windows Longhorn. Thanks a lot for this information. This is 6% gain, which is much more consistent with the slide: IronPython 1.1: 109K IronPython 2.0a1: 116K This seems to suggest that although IronPython 2.0 received performance improvements compared to IronPython 1.0 and 1.1, these improvements are quite dependent on underlying CLR runtime. Can someone from IronPython team explain why this is so? Following is a table summarizing effects of CLR runtime on relative performance of IronPython 1.0/1.1 and 2.0. Mono 1.2.4+: -32% Whidbey: -21% WinFX: +6% MIX07 (Orcas?): +12% -- Seo Sanghyeon From dinov at exchange.microsoft.com Thu May 17 19:47:30 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 17 May 2007 10:47:30 -0700 Subject: [IronPython] pystone results for 1.0 vs 2.0a1 on various runtimes In-Reply-To: <5b0248170705171041k6f2e80e8l5dfeb53ee5f02d29@mail.gmail.com> References: <5b0248170705171041k6f2e80e8l5dfeb53ee5f02d29@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DD352@DF-GRTDANE-MSG.exchange.corp.microsoft.com> In the Vista CLR (and this is in the Orcas CLR as well) there's an improvement to the performance of dispatching to a delegate closed over a parameter. We tend to be pushing on delegates more and more these days for things like the dynamic site infrastructure so this shows up there. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Thursday, May 17, 2007 10:42 AM To: Discussion of IronPython Subject: [IronPython] pystone results for 1.0 vs 2.0a1 on various runtimes I believe some of you may be interested in these results. In the video of DLR talk at MIX07, "the one and only powerpoint slide that actually contains content" shows pystone numbers for various versions of CPython and IronPython. (Seek to 37:50.) IronPython 1.0: 90K IronPython 2.0a1: 101K I assume these numbers are on Microsoft .NET included in Windows Vista. (Is it Orcas instead? Maybe that's why this differs from WinFX result below?) It shows 12% gain in pystone numbers. (I also note that IronPython 1.0 and 1.1 are virtually identical in terms of performance.) However, I can't reproduce this performance gain on Mono. The best of 3 results on my laptop gives 32% loss: IronPython 1.0: 31K IronPython 2.0a1: 21K Confused, I ran pystone on Windows XP PC to verify. Again, the results didn't match the slide (21% loss): IronPython 1.1: 68K IronPython 2.0a1: 54K I messaged M. David Peterson about the issue, and he gave me the results on Windows Longhorn. Thanks a lot for this information. This is 6% gain, which is much more consistent with the slide: IronPython 1.1: 109K IronPython 2.0a1: 116K This seems to suggest that although IronPython 2.0 received performance improvements compared to IronPython 1.0 and 1.1, these improvements are quite dependent on underlying CLR runtime. Can someone from IronPython team explain why this is so? Following is a table summarizing effects of CLR runtime on relative performance of IronPython 1.0/1.1 and 2.0. Mono 1.2.4+: -32% Whidbey: -21% WinFX: +6% MIX07 (Orcas?): +12% -- 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 Thu May 17 19:53:23 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 17 May 2007 10:53:23 -0700 Subject: [IronPython] Referring to Python types in Xaml In-Reply-To: References: <7AD436E4270DD54A94238001769C222791BC5DD30D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DD359@DF-GRTDANE-MSG.exchange.corp.microsoft.com> On addressing the typing issues: We haven't yet added any support for creating static types to the DLR. Currently we seem to be leaning in the direction of making it easy for static languages to use the DLR languages (obviously an important goal anyway :) ) but not much is settled here. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Bish Bosh Sent: Thursday, May 17, 2007 10:42 AM To: Discussion of IronPython Subject: Re: [IronPython] Referring to Python types in Xaml Interesting. My intention is not to have any C# in the projects so cooking my own type by that method is out. I guess people are just not using IP as a one for one replacement for C# as I had hoped to. In the two cases I talked about in post I guess I have workarounds. For creating instances I can create them in Python code and add them to the Resource database for use in the Xaml. For templating I can create a typeless data template and simply refer to this when I display the collection rather than have the system find this template automatically by type. No biggie really for the simple apps I'm doing, the benefits of using Python and Xaml outweigh these wrinkles. I wonder if the DLR is addressing these sort of typing issues? Up to now I'm a little unclear what those chaps are up to. Thanks for your prompt answer. On 5/17/07, Dino Viehland wrote: > We don't generate a type that can be easily consumed from static languages. Can you use an interface in the DataTemplate line, eg: > > > > If so then you could declare an interface in C# (or find an existing one which has what you want) and inherit & implement the interface in Python. Then the interface will be the bridge between the static & dynamic worlds. > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Bish Bosh > Sent: Thursday, May 17, 2007 8:46 AM > To: users at lists.ironpython.com > Subject: [IronPython] Referring to Python types in Xaml > > What is the mechanism for making types in the Python domain available > to the WPF type system for use in a Xaml file? > > In the code below I am refering to the Python class to do some > formatting but would have the same problem if I was trying to create > an instance of a Python class in the Xaml file. Any ideas? I'm pretty > sure I'm missing something simple but fundamental. As usual. > > In Python file I have a type: > > class FancyData(ObservableCollection[str]): > pass > > The collection to be displayed I am adding as an application resource: > > app.Resources.Add('collection', FancyData()) > > So it can be bound to as expected in the Xaml: > > > > In Xaml file I would like to refer to the type to do some formatting: > > > > ... > > I get the error: > > File data1.py, line 108, in Initialize > File , line 0, in _stub_##77 > File data1.py, line 26, in LoadXaml > File , line 0, in _stub_##87 > File PresentationFramework, line unknown, in Load > File PresentationFramework, line unknown, in XmlTreeBuildDefault > File PresentationFramework, line unknown, in Parse > File PresentationFramework, line unknown, in ParseFragment > File PresentationFramework, line unknown, in _Parse > File PresentationFramework, line unknown, in ReadXaml > File PresentationFramework, line unknown, in Read > SystemError: Type reference cannot find public type named 'FancyData'. > _______________________________________________ _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From unittesting at gmail.com Thu May 17 20:21:09 2007 From: unittesting at gmail.com (Bish Bosh) Date: Thu, 17 May 2007 14:21:09 -0400 Subject: [IronPython] Referring to Python types in Xaml In-Reply-To: <7AD436E4270DD54A94238001769C222791BC5DD359@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222791BC5DD30D@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <7AD436E4270DD54A94238001769C222791BC5DD359@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: Sorry I didn't realise you were 'those chaps'. Great work ;-) On 5/17/07, Dino Viehland wrote: > On addressing the typing issues: We haven't yet added any support for creating static types to the DLR. Currently we seem to be leaning in the direction of making it easy for static languages to use the DLR languages (obviously an important goal anyway :) ) but not much is settled here. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Bish Bosh > Sent: Thursday, May 17, 2007 10:42 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Referring to Python types in Xaml > > I wonder if the DLR is addressing these sort of typing issues? Up to > now I'm a little unclear what those chaps are up to. > From miguel at novell.com Thu May 17 20:21:23 2007 From: miguel at novell.com (Miguel de Icaza) Date: Thu, 17 May 2007 14:21:23 -0400 Subject: [IronPython] pystone results for 1.0 vs 2.0a1 on variousruntimes In-Reply-To: <1179426030.11014.1.camel@erandi.dom> References: <5b0248170705171041k6f2e80e8l5dfeb53ee5f02d29@mail.gmail.com> <1179426030.11014.1.camel@erandi.dom> Message-ID: <1179426083.11014.4.camel@erandi.dom> Hello Dino, > In the Vista CLR (and this is in the Orcas CLR as well) there's an > improvement to the performance of dispatching to a delegate closed > over a parameter. We tend to be pushing on delegates more and more > these days for things like the dynamic site infrastructure so this > shows up there. Could you explain a bit more what this optimization does? It might be interesting to have this implemented in the Mono runtime as well. Miguel. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo > Sent: Thursday, May 17, 2007 10:42 AM > To: Discussion of IronPython > Subject: [IronPython] pystone results for 1.0 vs 2.0a1 on various runtimes > > I believe some of you may be interested in these results. > > In the video of DLR talk at MIX07, "the one and only powerpoint slide > that actually contains content" shows pystone numbers for various > versions of CPython and IronPython. (Seek to 37:50.) > > IronPython 1.0: 90K > IronPython 2.0a1: 101K > > I assume these numbers are on Microsoft .NET included in Windows > Vista. (Is it Orcas instead? Maybe that's why this differs from WinFX > result below?) > > It shows 12% gain in pystone numbers. (I also note that IronPython 1.0 > and 1.1 are virtually identical in terms of performance.) > > However, I can't reproduce this performance gain on Mono. The best of > 3 results on my laptop gives 32% loss: > > IronPython 1.0: 31K > IronPython 2.0a1: 21K > > Confused, I ran pystone on Windows XP PC to verify. Again, the results > didn't match the slide (21% loss): > > IronPython 1.1: 68K > IronPython 2.0a1: 54K > > I messaged M. David Peterson about the issue, and he gave me the > results on Windows Longhorn. Thanks a lot for this information. This > is 6% gain, which is much more consistent with the slide: > > IronPython 1.1: 109K > IronPython 2.0a1: 116K > > This seems to suggest that although IronPython 2.0 received > performance improvements compared to IronPython 1.0 and 1.1, these > improvements are quite dependent on underlying CLR runtime. Can > someone from IronPython team explain why this is so? > > Following is a table summarizing effects of CLR runtime on relative > performance of IronPython 1.0/1.1 and 2.0. > > Mono 1.2.4+: -32% > Whidbey: -21% > WinFX: +6% > MIX07 (Orcas?): +12% > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Thu May 17 21:10:50 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 17 May 2007 12:10:50 -0700 Subject: [IronPython] pystone results for 1.0 vs 2.0a1 on variousruntimes In-Reply-To: <1179426083.11014.4.camel@erandi.dom> References: <5b0248170705171041k6f2e80e8l5dfeb53ee5f02d29@mail.gmail.com> <1179426030.11014.1.camel@erandi.dom> <1179426083.11014.4.camel@erandi.dom> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DD39F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> My vague recollection is that it involved not shuffling the parameters around on the stack to make the call where as we used to do this before (for not real good reason). But I could be completely wrong :). I'll follow up with the person who made the change and get back to you. The CLR team is moving offices over the next couple of days so it may not be until early next week. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Miguel de Icaza Sent: Thursday, May 17, 2007 11:21 AM To: Discussion of IronPython Subject: Re: [IronPython] pystone results for 1.0 vs 2.0a1 on variousruntimes Hello Dino, > In the Vista CLR (and this is in the Orcas CLR as well) there's an > improvement to the performance of dispatching to a delegate closed > over a parameter. We tend to be pushing on delegates more and more > these days for things like the dynamic site infrastructure so this > shows up there. Could you explain a bit more what this optimization does? It might be interesting to have this implemented in the Mono runtime as well. Miguel. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo > Sent: Thursday, May 17, 2007 10:42 AM > To: Discussion of IronPython > Subject: [IronPython] pystone results for 1.0 vs 2.0a1 on various runtimes > > I believe some of you may be interested in these results. > > In the video of DLR talk at MIX07, "the one and only powerpoint slide > that actually contains content" shows pystone numbers for various > versions of CPython and IronPython. (Seek to 37:50.) > > IronPython 1.0: 90K > IronPython 2.0a1: 101K > > I assume these numbers are on Microsoft .NET included in Windows > Vista. (Is it Orcas instead? Maybe that's why this differs from WinFX > result below?) > > It shows 12% gain in pystone numbers. (I also note that IronPython 1.0 > and 1.1 are virtually identical in terms of performance.) > > However, I can't reproduce this performance gain on Mono. The best of > 3 results on my laptop gives 32% loss: > > IronPython 1.0: 31K > IronPython 2.0a1: 21K > > Confused, I ran pystone on Windows XP PC to verify. Again, the results > didn't match the slide (21% loss): > > IronPython 1.1: 68K > IronPython 2.0a1: 54K > > I messaged M. David Peterson about the issue, and he gave me the > results on Windows Longhorn. Thanks a lot for this information. This > is 6% gain, which is much more consistent with the slide: > > IronPython 1.1: 109K > IronPython 2.0a1: 116K > > This seems to suggest that although IronPython 2.0 received > performance improvements compared to IronPython 1.0 and 1.1, these > improvements are quite dependent on underlying CLR runtime. Can > someone from IronPython team explain why this is so? > > Following is a table summarizing effects of CLR runtime on relative > performance of IronPython 1.0/1.1 and 2.0. > > Mono 1.2.4+: -32% > Whidbey: -21% > WinFX: +6% > MIX07 (Orcas?): +12% > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Thu May 17 21:31:00 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 17 May 2007 12:31:00 -0700 Subject: [IronPython] pystone results for 1.0 vs 2.0a1 on variousruntimes In-Reply-To: <7AD436E4270DD54A94238001769C222791BC5DD39F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <5b0248170705171041k6f2e80e8l5dfeb53ee5f02d29@mail.gmail.com> <1179426030.11014.1.camel@erandi.dom> <1179426083.11014.4.camel@erandi.dom> <7AD436E4270DD54A94238001769C222791BC5DD39F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DD3B1@DF-GRTDANE-MSG.exchange.corp.microsoft.com> And I was completely wrong :) The change was to no longer wrap LCG delegates inside a MultiCast delegate removing the overhead of calling through the multicast delegate. The multicast delegate was just a convenience for tracking the lifetime of the delegate and now the GC does that instead. I don't know if that'll apply to Mono or not but maybe it gives you some ideas on where to look for own improvements :). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Thursday, May 17, 2007 12:11 PM To: Discussion of IronPython Subject: Re: [IronPython] pystone results for 1.0 vs 2.0a1 on variousruntimes My vague recollection is that it involved not shuffling the parameters around on the stack to make the call where as we used to do this before (for not real good reason). But I could be completely wrong :). I'll follow up with the person who made the change and get back to you. The CLR team is moving offices over the next couple of days so it may not be until early next week. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Miguel de Icaza Sent: Thursday, May 17, 2007 11:21 AM To: Discussion of IronPython Subject: Re: [IronPython] pystone results for 1.0 vs 2.0a1 on variousruntimes Hello Dino, > In the Vista CLR (and this is in the Orcas CLR as well) there's an > improvement to the performance of dispatching to a delegate closed > over a parameter. We tend to be pushing on delegates more and more > these days for things like the dynamic site infrastructure so this > shows up there. Could you explain a bit more what this optimization does? It might be interesting to have this implemented in the Mono runtime as well. Miguel. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo > Sent: Thursday, May 17, 2007 10:42 AM > To: Discussion of IronPython > Subject: [IronPython] pystone results for 1.0 vs 2.0a1 on various runtimes > > I believe some of you may be interested in these results. > > In the video of DLR talk at MIX07, "the one and only powerpoint slide > that actually contains content" shows pystone numbers for various > versions of CPython and IronPython. (Seek to 37:50.) > > IronPython 1.0: 90K > IronPython 2.0a1: 101K > > I assume these numbers are on Microsoft .NET included in Windows > Vista. (Is it Orcas instead? Maybe that's why this differs from WinFX > result below?) > > It shows 12% gain in pystone numbers. (I also note that IronPython 1.0 > and 1.1 are virtually identical in terms of performance.) > > However, I can't reproduce this performance gain on Mono. The best of > 3 results on my laptop gives 32% loss: > > IronPython 1.0: 31K > IronPython 2.0a1: 21K > > Confused, I ran pystone on Windows XP PC to verify. Again, the results > didn't match the slide (21% loss): > > IronPython 1.1: 68K > IronPython 2.0a1: 54K > > I messaged M. David Peterson about the issue, and he gave me the > results on Windows Longhorn. Thanks a lot for this information. This > is 6% gain, which is much more consistent with the slide: > > IronPython 1.1: 109K > IronPython 2.0a1: 116K > > This seems to suggest that although IronPython 2.0 received > performance improvements compared to IronPython 1.0 and 1.1, these > improvements are quite dependent on underlying CLR runtime. Can > someone from IronPython team explain why this is so? > > Following is a table summarizing effects of CLR runtime on relative > performance of IronPython 1.0/1.1 and 2.0. > > Mono 1.2.4+: -32% > Whidbey: -21% > WinFX: +6% > MIX07 (Orcas?): +12% > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ 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 jeff at taupro.com Fri May 18 17:04:31 2007 From: jeff at taupro.com (Jeff Rush) Date: Fri, 18 May 2007 10:04:31 -0500 Subject: [IronPython] Questions about IronPython re Forrester Survey Message-ID: <464DC07F.3090104@taupro.com> Time is short and I'm still looking for answers to some questions about IronPython, so that it makes a good showing in the Forrester survey. 1) How is the project governed? How does the IronPython community make decisions on what goes into a release? 2) How many committers to the IronPython source are there? Open to outside people or just Microsoft? 3) Does IronPython have a formal defined release plan? Every 6-months? Whenever it feels right? 4) Some crude idea of how many new major and minor features were added in the last release? This is to give some idea of its current rate of evolution/stability in features. 5) Does IronPython yet run under Mono? Basically, is IronPython today still tied to Windows or is it cross-platform? Thanks for any one-line answers you can dash off to me today. Jeff Rush Python Advocacy Coordinator From sanxiyn at gmail.com Fri May 18 17:19:08 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Sat, 19 May 2007 00:19:08 +0900 Subject: [IronPython] Questions about IronPython re Forrester Survey In-Reply-To: <464DC07F.3090104@taupro.com> References: <464DC07F.3090104@taupro.com> Message-ID: <5b0248170705180819u4e1c6265g26479e743753a653@mail.gmail.com> 2007/5/19, Jeff Rush : > 5) Does IronPython yet run under Mono? Basically, is IronPython today still > tied to Windows or is it cross-platform? Other questions are better answered by IronPython team, but I can answer this one. IronPython 1.1 runs flawlessly on Mono versions later than 1.2.3. (But not out of the box on 1.2.2 if I recall correctly.) Mono 1.2.3 was released 2007-01-31. IronPython 1.1 was released 2007-04-17. Mono has been able to run IronPython for a long time. For example, the release note for Mono 1.1.16 (released 2006-07-06) notes that the release can run IronPython 1.0 Beta 8, then-current version of IronPython. It is true that new IronPython releases often exposed problems in Mono runtime, but they have been quickly fixed. Things have stablized since the release of IronPython 1.0 Final. That is, new IronPython releases no longer expose Mono bugs and usually don't need specific fixes. Well, DLR-based IronPython 2.0 Alpha 1 again exposed bunch of problems in Mono, but they are now all fixed too. -- Seo Sanghyeon From dinov at exchange.microsoft.com Fri May 18 18:26:13 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Fri, 18 May 2007 09:26:13 -0700 Subject: [IronPython] Questions about IronPython re Forrester Survey In-Reply-To: <464DC07F.3090104@taupro.com> References: <464DC07F.3090104@taupro.com> Message-ID: <7AD436E4270DD54A94238001769C222791BC83259E@DF-GRTDANE-MSG.exchange.corp.microsoft.com> For the decisions on what goes into releases... For small issues and requests we track these on CodePlex and pick them largely based upon the number of votes. For minor releases we also take into consideration how destabilizing the change will be. Currently we don't support external contributions. Typically there are 2-4 developers and 2-4 test developers. Those numbers get bigger and fluctuate as you step back and look at the wider DLR work, more languages, and various tools and support that build on top of IronPython. That makes it hard to give you an exact number as being a small team we do bounce around a bit. Release plans are a little in flux now but let me just give you some historical data points. During development v1.0 we typically shipped a new alpha/beta every 3 to 4 weeks. We also uploaded the current source tree to our CodePlex site on a per-checkin basis. We still have some infrastructure to get in place for the nightly source codes and some internal coordination around release cycles. We went dark to do much of the initial work on v2.0 but now that v2.0 Alpha 1 has been released the plan is to get back into a similar pattern. Major releases have been more about when they're ready. Looking at v1.1 for the last release: We had some on-going feature work that did not make the bar for v1.0 as it wasn't done in time and couldn't make it into betas, we did new feature work for the most popular features on CodePlex, and then we did a number of non-destabilizing targeted bug fixes for the most requested bugs on CodePlex. I think Seo covered the Mono side. ________________________________________ From: users-bounces at lists.ironpython.com [users-bounces at lists.ironpython.com] On Behalf Of Jeff Rush [jeff at taupro.com] Sent: Friday, May 18, 2007 8:04 AM To: Discussion of IronPython Subject: [IronPython] Questions about IronPython re Forrester Survey Time is short and I'm still looking for answers to some questions about IronPython, so that it makes a good showing in the Forrester survey. 1) How is the project governed? How does the IronPython community make decisions on what goes into a release? 2) How many committers to the IronPython source are there? Open to outside people or just Microsoft? 3) Does IronPython have a formal defined release plan? Every 6-months? Whenever it feels right? 4) Some crude idea of how many new major and minor features were added in the last release? This is to give some idea of its current rate of evolution/stability in features. 5) Does IronPython yet run under Mono? Basically, is IronPython today still tied to Windows or is it cross-platform? Thanks for any one-line answers you can dash off to me today. Jeff Rush Python Advocacy Coordinator _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From miguel at novell.com Fri May 18 07:27:06 2007 From: miguel at novell.com (Miguel de Icaza) Date: Fri, 18 May 2007 01:27:06 -0400 Subject: [IronPython] pystone results for 1.0 vs 2.0a1 on variousruntimes In-Reply-To: <1179434346.4083.2.camel@erandi.dom> References: <5b0248170705171041k6f2e80e8l5dfeb53ee5f02d29@mail.gmail.com> <1179426030.11014.1.camel@erandi.dom> <1179426083.11014.4.camel@erandi.dom> <7AD436E4270DD54A94238001769C222791BC5DD39F@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <1179434346.4083.2.camel@erandi.dom> Message-ID: <1179466026.3949.22.camel@erandi.dom> Hello Dino, > The change was to no longer wrap LCG delegates inside a MultiCast > delegate removing the overhead of calling through the multicast > delegate. The multicast delegate was just a convenience for tracking > the lifetime of the delegate and now the GC does that instead. I > don't know if that'll apply to Mono or not but maybe it gives you some > ideas on where to look for own improvements :). Thanks for the pointers! We will certainly look at this area. Miguel. From fuzzyman at voidspace.org.uk Fri May 18 20:14:35 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 18 May 2007 19:14:35 +0100 Subject: [IronPython] None in sys.path Message-ID: <464DED0B.1000403@voidspace.org.uk> Hello all, Weird pseudo-bug in IronPython 1.1. If you accidentally (!) None into sys.path then a failed import will raise a TypeError rather than an ImportError: >>> import sys >>> sys.path.append(None) >>> import wibble Traceback (most recent call last): File , line 0, in ##81 File , line 0, in __import__##4 File mscorlib, line unknown, in Combine TypeError: Value cannot be null. Parameter name: path1 >>> CPython is resilient against this, ignoring the entry. Maybe this isn't exactly a *bug* in IronPython - but it was the cause of a problem that took us a while to find... :-) Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml From m_tayseer82 at yahoo.com Sat May 19 15:24:02 2007 From: m_tayseer82 at yahoo.com (Mohammad Tayseer) Date: Sat, 19 May 2007 06:24:02 -0700 (PDT) Subject: [IronPython] How can I convince people to use IronPython? Message-ID: <967856.79158.qm@web31115.mail.mud.yahoo.com> Hello I'm going to make a presentation about IronPython. I want to show the power & simplicity of IronPython & dynamic languages. The audience are expected to have a good knowledge of programming, but none of them has knowledge of dynamic languages. I was thinking of implementing a very simple CMS: the user can define the model in Python (using django-like APIs) & the framework will generate ASP.NET form for it. Unfortunately I don't think the time will be enough to do that (about 45 minutes). Any Ideas? I want to show them things which are hard to do in C#. Thanks Mohammad Tayseer http://spellcoder.com/blogs/tayseer --------------------------------- Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. -------------- next part -------------- An HTML attachment was scrubbed... URL: From redmoon17 at gmail.com Sun May 20 02:34:35 2007 From: redmoon17 at gmail.com (Kevin Chu) Date: Sun, 20 May 2007 08:34:35 +0800 Subject: [IronPython] How can I convince people to use IronPython? In-Reply-To: <967856.79158.qm@web31115.mail.mud.yahoo.com> References: <967856.79158.qm@web31115.mail.mud.yahoo.com> Message-ID: <41d7f4a90705191734s3c12be81s1d6513117993291@mail.gmail.com> you can check Microsoft ASP.NET Futures May 2007 . use *Dynamic Data Controls for ASP.NET and **Dynamic Languages Support in ASP.NET to show some sample.* On 5/19/07, Mohammad Tayseer wrote: > > Hello > > I'm going to make a presentation about IronPython. I want to show the > power & simplicity of IronPython & dynamic languages. The audience are > expected to have a good knowledge of programming, but none of them has > knowledge of dynamic languages. > > I was thinking of implementing a very simple CMS: the user can define the > model in Python (using django-like APIs) & the framework will generate > ASP.NET form for it. Unfortunately I don't think the time will be enough > to do that (about 45 minutes). > > Any Ideas? I want to show them things which are hard to do in C#. > > Thanks > > > Mohammad Tayseer > http://spellcoder.com/blogs/tayseer > > ------------------------------ > Building a website is a piece of cake. > Yahoo! Small Business gives you all the tools to get online. > > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- Once in a Redmoon -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Sun May 20 17:44:07 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 21 May 2007 00:44:07 +0900 Subject: [IronPython] Is bug #7531 really fixed? Message-ID: <5b0248170705200844j61e2963fj1978fd51d5c5a1c@mail.gmail.com> http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7531 My test for this still fails, but it may be Mono-specific... Can anyone test this on IronPython 1.1? -- Seo Sanghyeon From fuzzyman at voidspace.org.uk Sun May 20 17:49:40 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 20 May 2007 16:49:40 +0100 Subject: [IronPython] Is bug #7531 really fixed? In-Reply-To: <5b0248170705200844j61e2963fj1978fd51d5c5a1c@mail.gmail.com> References: <5b0248170705200844j61e2963fj1978fd51d5c5a1c@mail.gmail.com> Message-ID: <46506E14.3080101@voidspace.org.uk> Sanghyeon Seo wrote: > http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=7531 > > My test for this still fails, but it may be Mono-specific... Can > anyone test this on IronPython 1.1? > > It prints 'xabc' with IronPython 1.1 on Windoze and .NET. Michael From sanxiyn at gmail.com Sun May 20 18:04:44 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 21 May 2007 01:04:44 +0900 Subject: [IronPython] Is bug #7531 really fixed? In-Reply-To: <46506E14.3080101@voidspace.org.uk> References: <5b0248170705200844j61e2963fj1978fd51d5c5a1c@mail.gmail.com> <46506E14.3080101@voidspace.org.uk> Message-ID: <5b0248170705200904pde0a2edw6e28d23bb5c250c0@mail.gmail.com> 2007/5/21, Michael Foord : > It prints 'xabc' with IronPython 1.1 on Windoze and .NET. Thanks. Will report as a Mono bug. -- Seo Sanghyeon From sanxiyn at gmail.com Sun May 20 19:41:50 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 21 May 2007 02:41:50 +0900 Subject: [IronPython] [ANN] IronPython Community Edition r6 Message-ID: <5b0248170705201041lf3446f3t94e7e4ab86d5b0c@mail.gmail.com> This is the sixth 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 release is built with Mono 1.2.3.1. As this release has dropped a patch to support Mono without Socket.{Send,Receive}BufferSize implementation, it won't work with Mono versions below 1.2.3. It has been a long time (more than 5 months) since the last release. In the mean time, DLR-based IronPython 2.0 Alpha 1 was revealed, and it was subsequently ported to Mono. As this codebase is still new, IPCE will be based on IronPython 1.1 for the time being. Also note that IronPython 2.0 Alpha 1 has significant performance regression on Mono (but not on MS.NET) compared to IronPython 1.1. http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004915.html Changes in this release follow. IronPython Updated to IronPython 1.1. Libraries Huge improvements to AST support. Support inspect.getargspec(). Pickle integration with .NET Serialization. platform module that can handle IronPython. (Anthony Baxter) Implement os.access(). (Rachel Hestilow) Bundles pybench benchmark (thanks to platform module). pyflakes code checker (thanks to AST support). wsgiref synced to 2.5.1. Patches You can read the summary of applied patches here. http://fepy.sourceforge.net/patches.html New in this release: patch-ironpython-import-hack -- Seo Sanghyeon From miuler at gmail.com Mon May 21 02:15:51 2007 From: miuler at gmail.com (Hector Miuler Malpica Gallegos) Date: Mon, 21 May 2007 00:15:51 +0000 Subject: [IronPython] =?utf-8?b?wqHDmm5ldGUgYSBMYXN0LmZtIQ==?= Message-ID: <9e875a39ebd081ff1aff743fc39deee4@www.lastfm.es> Hola IronPython, Agr?game a tus amigos en Last.fm y podremos compartir nuestros gustos musicales :) Esta es la m?sica que escucho: http://www.lastfm.es/user/Miuler/?invitedby=Miuler&tp=ff_tp_b -------- Registrarse es gratis y te llevar? menos de un minuto. Simplemente haz clic para a?adirte a mi lista de amigos. http://www.lastfm.es/join/?invitedby=Miuler&tp=ff_tp_b Visita mi perfil y d?jame una nota, ?nos vemos! Hector Miuler Malpica Gallegos PS: Soy 'Miuler' en Last.fm -------- Te ha llegado este mensaje porque alguien que conoces (Hector Miuler Malpica Gallegos) te ha enviado una invitaci?n para Last.fm. No hemos guardado tu direcci?n ni nos pondremos en contacto contigo, a menos que lo desees. Encontrar?s m?s informaci?n en nuestra pol?tica de privacidad: http://www.lastfm.es/help/privacy.php -------------- next part -------------- An HTML attachment was scrubbed... URL: From miuler at gmail.com Mon May 21 02:15:51 2007 From: miuler at gmail.com (Hector Miuler Malpica Gallegos) Date: Mon, 21 May 2007 00:15:51 +0000 Subject: [IronPython] =?utf-8?b?wqHDmm5ldGUgYSBMYXN0LmZtIQ==?= Message-ID: <85371d7d60e82603f64a5aba54e161de@www.lastfm.es> Hola IronPython, Agr?game a tus amigos en Last.fm y podremos compartir nuestros gustos musicales :) Esta es la m?sica que escucho: http://www.lastfm.es/user/Miuler/?invitedby=Miuler&tp=ff_tp_b -------- Registrarse es gratis y te llevar? menos de un minuto. Simplemente haz clic para a?adirte a mi lista de amigos. http://www.lastfm.es/join/?invitedby=Miuler&tp=ff_tp_b Visita mi perfil y d?jame una nota, ?nos vemos! Hector Miuler Malpica Gallegos PS: Soy 'Miuler' en Last.fm -------- Te ha llegado este mensaje porque alguien que conoces (Hector Miuler Malpica Gallegos) te ha enviado una invitaci?n para Last.fm. No hemos guardado tu direcci?n ni nos pondremos en contacto contigo, a menos que lo desees. Encontrar?s m?s informaci?n en nuestra pol?tica de privacidad: http://www.lastfm.es/help/privacy.php -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmlhacker at gmail.com Mon May 21 06:41:02 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Sun, 20 May 2007 22:41:02 -0600 Subject: [IronPython] [ANN] IronPython Community Edition r6 In-Reply-To: <5b0248170705201041lf3446f3t94e7e4ab86d5b0c@mail.gmail.com> References: <5b0248170705201041lf3446f3t94e7e4ab86d5b0c@mail.gmail.com> Message-ID: Nice! > http://www.oreillynet.com/windows/blog/2007/05/seo_sanghyeonipce_ironpython_c_2.html On 5/20/07, Sanghyeon Seo wrote: > > This is the sixth 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 release is built with Mono 1.2.3.1. As this release has dropped a > patch to support Mono without Socket.{Send,Receive}BufferSize > implementation, it won't work with Mono versions below 1.2.3. > > It has been a long time (more than 5 months) since the last release. > In the mean time, DLR-based IronPython 2.0 Alpha 1 was revealed, and > it was subsequently ported to Mono. As this codebase is still new, > IPCE will be based on IronPython 1.1 for the time being. > > Also note that IronPython 2.0 Alpha 1 has significant performance > regression on Mono (but not on MS.NET) compared to IronPython 1.1. > > http://lists.ironpython.com/pipermail/users-ironpython.com/2007-May/004915.html > > Changes in this release follow. > > IronPython > > Updated to IronPython 1.1. > > Libraries > > Huge improvements to AST support. > Support inspect.getargspec(). > Pickle integration with .NET Serialization. > platform module that can handle IronPython. (Anthony Baxter) > Implement os.access(). (Rachel Hestilow) > > Bundles > > pybench benchmark (thanks to platform module). > pyflakes code checker (thanks to AST support). > wsgiref synced to 2.5.1. > > Patches > > You can read the summary of applied patches here. > http://fepy.sourceforge.net/patches.html > > New in this release: > patch-ironpython-import-hack > > -- > Seo Sanghyeon > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Tue May 22 04:06:46 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Tue, 22 May 2007 11:06:46 +0900 Subject: [IronPython] Dynamic languages on CLR idea -- from 2003 Message-ID: <5b0248170705211906s707b454ag257b825d3a38321@mail.gmail.com> Recently I found this interesting mail buried in mono-devel-list. Rodrigo B. de Oliveira on 2003-09-25 http://lists.ximian.com/pipermail/mono-devel-list/2003-September/002151.html via Monologue: http://www.go-mono.com/monologue/ To put this in context, Jim presented IronPython 0.2 at PyCon on 2004-03-24. By the way, I'm eagerly waiting for the next part of DLR series in Jim's blog! It would be especially interesting to read about above aspects of DLR, caching generated function stubs. -- Seo Sanghyeon From dinov at exchange.microsoft.com Tue May 22 04:22:34 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Mon, 21 May 2007 19:22:34 -0700 Subject: [IronPython] Dynamic languages on CLR idea -- from 2003 In-Reply-To: <5b0248170705211906s707b454ag257b825d3a38321@mail.gmail.com> References: <5b0248170705211906s707b454ag257b825d3a38321@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DD998@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I also stumbled onto this in my blog reading today. This is similar to what we do but we throw generics into the mix (so the Function delegate is strongly typed) and we also inline the test (IOW, a highly optimized CheckFunctionCache in the terms of the blog entry). Of course the tests disappear when we're strongly typed. Then we use this for more than just method dispatch. I too am looking forward to the next blog entry :) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Monday, May 21, 2007 7:07 PM To: Discussion of IronPython Subject: [IronPython] Dynamic languages on CLR idea -- from 2003 Recently I found this interesting mail buried in mono-devel-list. Rodrigo B. de Oliveira on 2003-09-25 http://lists.ximian.com/pipermail/mono-devel-list/2003-September/002151.html via Monologue: http://www.go-mono.com/monologue/ To put this in context, Jim presented IronPython 0.2 at PyCon on 2004-03-24. By the way, I'm eagerly waiting for the next part of DLR series in Jim's blog! It would be especially interesting to read about above aspects of DLR, caching generated function stubs. -- 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 Tue May 22 19:49:03 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 22 May 2007 10:49:03 -0700 Subject: [IronPython] None in sys.path In-Reply-To: <464DED0B.1000403@voidspace.org.uk> References: <464DED0B.1000403@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DDA60@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Thanks for the report Michael. I've opened bug #10474 for this (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=10474) and assigned it to the 2.0 Alpha 2 release for the time being. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, May 18, 2007 11:15 AM To: Discussion of IronPython Subject: [IronPython] None in sys.path Hello all, Weird pseudo-bug in IronPython 1.1. If you accidentally (!) None into sys.path then a failed import will raise a TypeError rather than an ImportError: >>> import sys >>> sys.path.append(None) >>> import wibble Traceback (most recent call last): File , line 0, in ##81 File , line 0, in __import__##4 File mscorlib, line unknown, in Combine TypeError: Value cannot be null. Parameter name: path1 >>> CPython is resilient against this, ignoring the entry. Maybe this isn't exactly a *bug* in IronPython - but it was the cause of a problem that took us a while to find... :-) Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From bewest at gmail.com Tue May 22 20:20:03 2007 From: bewest at gmail.com (Benjamin West) Date: Tue, 22 May 2007 11:20:03 -0700 Subject: [IronPython] urllib.urlopen(url).read() problem Message-ID: <8ad71be30705221120k55f67f21ie5de32f0c69e1ea5@mail.gmail.com> I was having trouble using urllib. I tried using IP 1.1, and IPCE-r6 and got the same results. I also tried pointing ipy at the stdlib in both a cygwin install and a windows install with similar results. Am I doing something wrong? urllib2 works. Thanks, Ben West --------------------------------------------------------------------------- ipy.exe -X:ExceptionDetail IronPython 1.1 (1.1) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> import urllib >>> r = urllib.urlopen('http://www.alexa.com/') >>> r > >>> r.read() Unable to read data from the transport connection: Cannot access a disposed object. Object name: 'System.Net.Sockets.Socket'.. at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) at IronPython.Runtime.PythonBinaryReader.ReadToEnd() in C:downloadsironpythonIronPython-1.1-SrcIronPython-1.1SrcIronPythonRuntimePythonFile.cs:line 144 at IronPython.Runtime.PythonFile.Read(Int32 size) in C:downloadsironpythonIronPython-1.1-SrcIronPython-1.1SrcIronPythonRuntimePythonFile.cs:line 1095 at IronPython.Runtime.PythonFile.Read() in C:downloadsironpythonIronPython-1.1-SrcIronPython-1.1SrcIronPythonRuntimePythonFile.cs:line 1084 at Read##161(Object ) at IronPython.Runtime.Calls.CallTarget1.Invoke(Object arg0) at IronPython.Runtime.Calls.FastCallableAny.CallInstance(ICallerContext context, Object arg0) in C:downloadsironpythonIronPython-1.1-SrcIronPython-1.1SrcIronPythonRuntimeCallsFastCallable.Generated.cs:line 186 at IronPython.Runtime.Calls.BoundBuiltinFunction.Call(ICallerContext context) in C:downloadsironpythonIronPython-1.1-SrcIronPython-1.1SrcIronPythonRuntimeCallsBuiltinFunction.Generated.cs:line 73 at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext context, Object func) in C:downloadsironpythonIronPython-1.1-SrcIronPython-1.1SrcIronPythonRuntimeOperationsOps.Generated.cs:line 78 at ##160(ModuleScope ) at IronPython.Hosting.CompiledCodeDelegate.Invoke(ModuleScope moduleScope) at IronPython.Hosting.CompiledCode.Run(ModuleScope moduleScope) in C:downloadsironpythonIronPython-1.1-SrcIronPython-1.1SrcIronPythonHostingCompiledCode.cs:line 46 at IronPython.Hosting.PythonEngine.ExecuteToConsole(String text, EngineModule engineModule, IDictionary`2 locals) in C:downloadsironpythonIronPython-1.1-SrcIronPython-1.1SrcIronPythonHostingPythonEngine.cs:line 492 at IronPython.Hosting.PythonEngine.ExecuteToConsole(String text) in C:downloadsironpythonIronPython-1.1-SrcIronPython-1.1SrcIronPythonHostingPythonEngine.cs:line 463 at IronPythonConsole.PythonCommandLine.DoOneInteractive() in C:downloadsironpythonIronPython-1.1-SrcIronPython-1.1SrcIronPythonConsolePythonCommandLine.cs:line 563 at IronPythonConsole.PythonCommandLine.b__6(Boolean& continueInteractionArgument) in C:downloadsironpythonIronPython-1.1-SrcIronPython-1.1SrcIronPythonConsolePythonCommandLine.cs:line 695 at IronPythonConsole.PythonCommandLine.TryInteractiveAction(InteractiveAction interactiveAction, Boolean& continueInteraction) in C:downloadsironpythonIronPython-1.1-SrcIronPython-1.1SrcIronPythonConsolePythonCommandLine.cs:line 605 at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, SocketError& errorCode) at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags) at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) IOError: Unable to read data from the transport connection: Cannot access a disposed object. Object name: 'System.Net.Sockets.Socket'.. >>> From michael_sweeney at agilent.com Tue May 22 21:37:15 2007 From: michael_sweeney at agilent.com (michael_sweeney at agilent.com) Date: Tue, 22 May 2007 13:37:15 -0600 Subject: [IronPython] PythonEngine in separate AppDomain? Message-ID: <64B0479F895F194587EE70276364C5C6028A1E7F@wcosmb02.cos.agilent.com> Hi All, I have been using the PythonEngine to host IronPython in my application, it works great. I have a need to host the PythonEngine in a separate AppDomain and then provide an API back to the default app domain. I am running into the black-hole of Security issues. I get the following FileIOPermission inner-exception during the PythonEngine creation: at System.Runtime.CompilerServices.RuntimeHelpers._RunClassConstructor(IntPtr type) at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type) at IronPython.Hosting.PythonEngine.Initialize(EngineOptions engineOptions) in C:\tfs\Fusion\Main\Source\IronPython\IronPython\Hosting\PythonEngine.cs:line 175 at IronPython.Hosting.PythonEngine..ctor(EngineOptions engineOptions) in C:\tfs\Fusion\Main\Source\IronPython\IronPython\Hosting\PythonEngine.cs:line 141 at ConsoleApplication1.PythonInstance..ctor() in C:\temp\ConsoleApplication1\Program.cs:line 27 It appears that the PythonEngine is trying to create an assembly file in the OutputGenerator.cs file. I would like to know the magic to give the separate AppDomain the ability to write files. I have also gone as far as configuring the separate AppDomain with special security permissions, with no impact... that code is also below... I have trimmed down the application into the following test code: using System; using System.Collections.Generic; using System.Text; using System.IO; using System.Reflection; using IronPython.Hosting; using IronPython.Runtime; using IronPython.Runtime.Operations; using IronPython.Modules; namespace ConsoleApplication1 { [Serializable] public class PythonInstance { // IronPython Modules private static PythonEngine _python; public PythonInstance() { // Create Python Engine EngineOptions options = new EngineOptions(); options.ExceptionDetail = true; options.ClrDebuggingEnabled = true; PythonInstance._python = new PythonEngine(options); } public void AddPythonPath(string path) { PythonInstance._python.AddToPath(path); } } class Program { static void Main(string[] args) { AppDomainSetup setup = new AppDomainSetup(); setup.ApplicationName = Assembly.GetEntryAssembly().FullName; setup.ApplicationBase = Path.GetDirectoryName(typeof(Program).Assembly.Location); AppDomain domain = AppDomain.CreateDomain("PythonDomain", null, setup); // Create Test Engine in remote domain object obj = domain.CreateInstanceAndUnwrap("ConsoleApplication1", "ConsoleApplication1.PythonInstance"); PythonInstance python = obj as PythonInstance; python.AddPythonPath(@"C:\temp"); } } } Code to give the app domain special permissions: private void SetAppDomainPolicy(AppDomain appDomain) { // Create an AppDomain policy level. PolicyLevel pLevel = PolicyLevel.CreateAppDomainLevel(); // The root code group of the policy level combines all // permissions of its children. PermissionSet ps = new PermissionSet(PermissionState.Unrestricted); ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.AllFlags)); UnionCodeGroup rootCodeGroup = new UnionCodeGroup(new AllMembershipCondition(), new PolicyStatement(ps, PolicyStatementAttribute.Nothing)); NamedPermissionSet localIntranet = FindNamedPermissionSet("LocalIntranet"); // The following code limits all code on this machine to local intranet permissions // when running in this application domain. UnionCodeGroup virtualIntranet = new UnionCodeGroup(new ZoneMembershipCondition(SecurityZone.MyComputer), new PolicyStatement(localIntranet, PolicyStatementAttribute.Nothing)); virtualIntranet.Name = "Virtual Intranet"; // Add the code groups to the policy level. rootCodeGroup.AddChild(virtualIntranet); pLevel.RootCodeGroup = rootCodeGroup; appDomain.SetAppDomainPolicy(pLevel); } private NamedPermissionSet FindNamedPermissionSet(string name) { IEnumerator policyEnumerator = SecurityManager.PolicyHierarchy(); while (policyEnumerator.MoveNext()) { PolicyLevel currentLevel = (PolicyLevel)policyEnumerator.Current; if (currentLevel.Label == "Machine") { IList namedPermissions = currentLevel.NamedPermissionSets; IEnumerator namedPermission = namedPermissions.GetEnumerator(); while (namedPermission.MoveNext()) { if (((NamedPermissionSet)namedPermission.Current).Name == name) { return ((NamedPermissionSet)namedPermission.Current); } } } } return null; } Thanks in advance... Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From xmlhacker at gmail.com Tue May 22 22:28:20 2007 From: xmlhacker at gmail.com (M. David Peterson) Date: Tue, 22 May 2007 14:28:20 -0600 Subject: [IronPython] VST/DLR running on Silverlight! Message-ID: FYI... Peter Fisk now has Vista Smalltalk running via the DLR inside of Silverlight. http://vistasmalltalk.wordpress.com/2007/05/22/smalltalk-in-silverlight-workspace-windows/ and http://vistasmalltalk.wordpress.com/2007/05/22/smalltalk-in-silverlight-macintosh-test/ -- /M:D M. David Peterson http://mdavid.name | http://www.oreillynet.com/pub/au/2354 | http://dev.aol.com/blog/3155 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Tue May 22 22:54:14 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 22 May 2007 13:54:14 -0700 Subject: [IronPython] PythonEngine in separate AppDomain? In-Reply-To: <64B0479F895F194587EE70276364C5C6028A1E7F@wcosmb02.cos.agilent.com> References: <64B0479F895F194587EE70276364C5C6028A1E7F@wcosmb02.cos.agilent.com> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DDB40@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Are you getting this even if you don't do anything w/ permissions? You're going to have a tough time running IronPython in partial trust before .NET 2.0 SP1 or Orcas. In SP1 of the CLR (which is the CLR included w/ Orcas and I believe will ship stand-alone as its own SP at some point) various portions of Reflection.Emit have had the appropriate security hardening to ensure they work properly in partial trust. Unfortunately both of those are still beta code :(. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com Sent: Tuesday, May 22, 2007 12:37 PM To: users at lists.ironpython.com Subject: [IronPython] PythonEngine in separate AppDomain? Hi All, I have been using the PythonEngine to host IronPython in my application, it works great. I have a need to host the PythonEngine in a separate AppDomain and then provide an API back to the default app domain. I am running into the black-hole of Security issues. I get the following FileIOPermission inner-exception during the PythonEngine creation: at System.Runtime.CompilerServices.RuntimeHelpers._RunClassConstructor(IntPtr type) at System.Runtime.CompilerServices.RuntimeHelpers.RunClassConstructor(RuntimeTypeHandle type) at IronPython.Hosting.PythonEngine.Initialize(EngineOptions engineOptions) in C:\tfs\Fusion\Main\Source\IronPython\IronPython\Hosting\PythonEngine.cs:line 175 at IronPython.Hosting.PythonEngine..ctor(EngineOptions engineOptions) in C:\tfs\Fusion\Main\Source\IronPython\IronPython\Hosting\PythonEngine.cs:line 141 at ConsoleApplication1.PythonInstance..ctor() in C:\temp\ConsoleApplication1\Program.cs:line 27 It appears that the PythonEngine is trying to create an assembly file in the OutputGenerator.cs file. I would like to know the magic to give the separate AppDomain the ability to write files. I have also gone as far as configuring the separate AppDomain with special security permissions, with no impact... that code is also below... I have trimmed down the application into the following test code: using System; using System.Collections.Generic; using System.Text; using System.IO; using System.Reflection; using IronPython.Hosting; using IronPython.Runtime; using IronPython.Runtime.Operations; using IronPython.Modules; namespace ConsoleApplication1 { [Serializable] public class PythonInstance { // IronPython Modules private static PythonEngine _python; public PythonInstance() { // Create Python Engine EngineOptions options = new EngineOptions(); options.ExceptionDetail = true; options.ClrDebuggingEnabled = true; PythonInstance._python = new PythonEngine(options); } public void AddPythonPath(string path) { PythonInstance._python.AddToPath(path); } } class Program { static void Main(string[] args) { AppDomainSetup setup = new AppDomainSetup(); setup.ApplicationName = Assembly.GetEntryAssembly().FullName; setup.ApplicationBase = Path.GetDirectoryName(typeof(Program).Assembly.Location); AppDomain domain = AppDomain.CreateDomain("PythonDomain", null, setup); // Create Test Engine in remote domain object obj = domain.CreateInstanceAndUnwrap("ConsoleApplication1", "ConsoleApplication1.PythonInstance"); PythonInstance python = obj as PythonInstance; python.AddPythonPath(@"C:\temp"); } } } Code to give the app domain special permissions: private void SetAppDomainPolicy(AppDomain appDomain) { // Create an AppDomain policy level. PolicyLevel pLevel = PolicyLevel.CreateAppDomainLevel(); // The root code group of the policy level combines all // permissions of its children. PermissionSet ps = new PermissionSet(PermissionState.Unrestricted); ps.AddPermission(new SecurityPermission(SecurityPermissionFlag.AllFlags)); UnionCodeGroup rootCodeGroup = new UnionCodeGroup(new AllMembershipCondition(), new PolicyStatement(ps, PolicyStatementAttribute.Nothing)); NamedPermissionSet localIntranet = FindNamedPermissionSet("LocalIntranet"); // The following code limits all code on this machine to local intranet permissions // when running in this application domain. UnionCodeGroup virtualIntranet = new UnionCodeGroup(new ZoneMembershipCondition(SecurityZone.MyComputer), new PolicyStatement(localIntranet, PolicyStatementAttribute.Nothing)); virtualIntranet.Name = "Virtual Intranet"; // Add the code groups to the policy level. rootCodeGroup.AddChild(virtualIntranet); pLevel.RootCodeGroup = rootCodeGroup; appDomain.SetAppDomainPolicy(pLevel); } private NamedPermissionSet FindNamedPermissionSet(string name) { IEnumerator policyEnumerator = SecurityManager.PolicyHierarchy(); while (policyEnumerator.MoveNext()) { PolicyLevel currentLevel = (PolicyLevel)policyEnumerator.Current; if (currentLevel.Label == "Machine") { IList namedPermissions = currentLevel.NamedPermissionSets; IEnumerator namedPermission = namedPermissions.GetEnumerator(); while (namedPermission.MoveNext()) { if (((NamedPermissionSet)namedPermission.Current).Name == name) { return ((NamedPermissionSet)namedPermission.Current); } } } } return null; } Thanks in advance... Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Wed May 23 02:35:38 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 23 May 2007 09:35:38 +0900 Subject: [IronPython] urllib.urlopen(url).read() problem In-Reply-To: <8ad71be30705221120k55f67f21ie5de32f0c69e1ea5@mail.gmail.com> References: <8ad71be30705221120k55f67f21ie5de32f0c69e1ea5@mail.gmail.com> Message-ID: <5b0248170705221735h1c659e8bm45bff79b11577b1f@mail.gmail.com> 2007/5/23, Benjamin West : > I was having trouble using urllib. I tried using IP 1.1, and IPCE-r6 > and got the same results. I also tried pointing ipy at the stdlib in > both a cygwin install and a windows install with similar results. > > Am I doing something wrong? urllib2 works. > Thanks, > Ben West I think this is an IronPython bug. The simplest solution is to use FEPY_OPTIONS=network, which lets IPCE to use FePy's version of socket, select, and ssl module. More here: http://fepy.sourceforge.net/doc/fepy-options.html -- Seo Sanghyeon From bewest at gmail.com Wed May 23 03:00:01 2007 From: bewest at gmail.com (Benjamin West) Date: Tue, 22 May 2007 18:00:01 -0700 Subject: [IronPython] urllib.urlopen(url).read() problem In-Reply-To: <5b0248170705221735h1c659e8bm45bff79b11577b1f@mail.gmail.com> References: <8ad71be30705221120k55f67f21ie5de32f0c69e1ea5@mail.gmail.com> <5b0248170705221735h1c659e8bm45bff79b11577b1f@mail.gmail.com> Message-ID: <8ad71be30705221800g450c32dcw19bf0661b8b341a1@mail.gmail.com> > > Am I doing something wrong? urllib2 works. > > Thanks, > > Ben West > > I think this is an IronPython bug. > > The simplest solution is to use FEPY_OPTIONS=network, which lets IPCE > to use FePy's version of socket, select, and ssl module. More here: > > http://fepy.sourceforge.net/doc/fepy-options.html > > -- > Seo Sanghyeon Whoah. I was going to mention that I had also tried doing import fepy, fepy.install_option('fileobject') and fepy.install_option('network') and that it had still failed. However, I must have made some mistake, because fepy.install_option('network') also works. So evidently, urllib needs fepy's "network" option while urllib2 needs fepy's "fileobject" option. Thanks. -Ben From sanxiyn at gmail.com Wed May 23 09:29:48 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Wed, 23 May 2007 16:29:48 +0900 Subject: [IronPython] Is bug #7531 really fixed? In-Reply-To: <5b0248170705200904pde0a2edw6e28d23bb5c250c0@mail.gmail.com> References: <5b0248170705200844j61e2963fj1978fd51d5c5a1c@mail.gmail.com> <46506E14.3080101@voidspace.org.uk> <5b0248170705200904pde0a2edw6e28d23bb5c250c0@mail.gmail.com> Message-ID: <5b0248170705230029u7a931facib6d1b9f601d3dc83@mail.gmail.com> 2007/5/21, Sanghyeon Seo : > 2007/5/21, Michael Foord : > > It prints 'xabc' with IronPython 1.1 on Windoze and .NET. > > Thanks. Will report as a Mono bug. This is now Mono bug #81714. http://bugzilla.ximian.com/show_bug.cgi?id=81714 -- Seo Sanghyeon From dinov at exchange.microsoft.com Wed May 23 17:17:29 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 23 May 2007 08:17:29 -0700 Subject: [IronPython] urllib.urlopen(url).read() problem In-Reply-To: <8ad71be30705221800g450c32dcw19bf0661b8b341a1@mail.gmail.com> References: <8ad71be30705221120k55f67f21ie5de32f0c69e1ea5@mail.gmail.com> <5b0248170705221735h1c659e8bm45bff79b11577b1f@mail.gmail.com> <8ad71be30705221800g450c32dcw19bf0661b8b341a1@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DDC6A@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Thanks for the bug report Benjamin. And thanks for the workaround Seo. I've opened bug #10518 for this: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=10518. I haven't had a chance to look at the issue yet though. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Benjamin West Sent: Tuesday, May 22, 2007 6:00 PM To: Discussion of IronPython Subject: Re: [IronPython] urllib.urlopen(url).read() problem > > Am I doing something wrong? urllib2 works. > > Thanks, > > Ben West > > I think this is an IronPython bug. > > The simplest solution is to use FEPY_OPTIONS=network, which lets IPCE > to use FePy's version of socket, select, and ssl module. More here: > > http://fepy.sourceforge.net/doc/fepy-options.html > > -- > Seo Sanghyeon Whoah. I was going to mention that I had also tried doing import fepy, fepy.install_option('fileobject') and fepy.install_option('network') and that it had still failed. However, I must have made some mistake, because fepy.install_option('network') also works. So evidently, urllib needs fepy's "network" option while urllib2 needs fepy's "fileobject" option. Thanks. -Ben _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From michael_sweeney at agilent.com Wed May 23 18:22:05 2007 From: michael_sweeney at agilent.com (michael_sweeney at agilent.com) Date: Wed, 23 May 2007 10:22:05 -0600 Subject: [IronPython] PythonEngine in separate AppDomain? In-Reply-To: <7AD436E4270DD54A94238001769C222791BC5DDB40@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <64B0479F895F194587EE70276364C5C6028A1E7F@wcosmb02.cos.agilent.com> <7AD436E4270DD54A94238001769C222791BC5DDB40@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <64B0479F895F194587EE70276364C5C6028A223F@wcosmb02.cos.agilent.com> Hi Dino, I get this error with or without the permission code. Here is the problem I am trying to solve... We have a test tool that allows the load/reload of Python test scripts. It is implemented in CPython. We manipulate the sys.modules dictionary to "clean" out any modules the test module loaded. This "cleaning" allows the developers to quickly run/edit/reload/run the test scripts. We are porting this application to IronPython by hosting the PythonEngine in a C# application. The new tool allows the user to load .NET assemblies as well as the classic python modules. The ability to reload is handy. Since it is possible to unload AppDomains for the assembly based tests, I was thinking that just putting the PythonEngine in a separate AppDomain I could handle the unload the same way. This is when I started running into permission issues. I wanted to avoid the "cleaning" of the sys.modules dictionary because it has proved error-prone in the CPython implementation. I may have to start going down this path. Thanks for your feedback. Mike From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, May 22, 2007 1:54 PM To: Discussion of IronPython Subject: Re: [IronPython] PythonEngine in separate AppDomain? Are you getting this even if you don't do anything w/ permissions? You're going to have a tough time running IronPython in partial trust before .NET 2.0 SP1 or Orcas. In SP1 of the CLR (which is the CLR included w/ Orcas and I believe will ship stand-alone as its own SP at some point) various portions of Reflection.Emit have had the appropriate security hardening to ensure they work properly in partial trust. Unfortunately both of those are still beta code L. Thanks in advance... Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.couvreur at gmail.com Wed May 23 22:04:26 2007 From: julien.couvreur at gmail.com (Julien Couvreur) Date: Wed, 23 May 2007 13:04:26 -0700 Subject: [IronPython] Problem stepping into functions in debugger with F11 Message-ID: <919035ab0705231304u30f31f3fta587a63f35ffcd66@mail.gmail.com> Hi, I'm running a simple program below. I'm trying to "step into" the "add" function. But Visual Studio 2005 and the Microsoft CLR Debugger (from the .Net 2.0 SDK) both complain that: "There is no source code available for the current location." They then offer me to view the disassembly. Any ideas how to fix this? Note that I do have "Enable Just My Code" turned on (which is the default). Thanks, Julien Couvreur http://blog.monstuff.com Repro steps: 1) save the code below to debugger.ipy 2) Run ipy.exe debugger.ipy 3) You should get a prompt to start debugging the code with your favorite debugger, accept it 4) The code should be stopped at the breakpoint, you can step forward with F10 and then F11 5) Trying to step into the call to the "add" method fails as described above def add(a,b): return a+b import System.Diagnostics System.Diagnostics.Debugger.Break() print add(4, 4) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bewest at gmail.com Wed May 23 23:30:39 2007 From: bewest at gmail.com (Benjamin West) Date: Wed, 23 May 2007 14:30:39 -0700 Subject: [IronPython] how to apply guid Message-ID: <8ad71be30705231430p709690c2j17b7706c57b7b992@mail.gmail.com> How do I apply a GUID or other attributes to a class? All the examples I can find in C# use attributes. I haven't read much regarding using attributes in IronPython, except for a few messages in the archive. Is there some workaround? -Ben From dinov at exchange.microsoft.com Wed May 23 23:52:43 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 23 May 2007 14:52:43 -0700 Subject: [IronPython] how to apply guid In-Reply-To: <8ad71be30705231430p709690c2j17b7706c57b7b992@mail.gmail.com> References: <8ad71be30705231430p709690c2j17b7706c57b7b992@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DDDAA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> We don't yet support defining attributes from Python. It's a common feature request. For that you'll need to go to a static language like C# :(. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Benjamin West Sent: Wednesday, May 23, 2007 2:31 PM To: Discussion of IronPython Subject: [IronPython] how to apply guid How do I apply a GUID or other attributes to a class? All the examples I can find in C# use attributes. I haven't read much regarding using attributes in IronPython, except for a few messages in the archive. Is there some workaround? -Ben _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From bewest at gmail.com Thu May 24 00:39:40 2007 From: bewest at gmail.com (Benjamin West) Date: Wed, 23 May 2007 15:39:40 -0700 Subject: [IronPython] how to apply guid In-Reply-To: <7AD436E4270DD54A94238001769C222791BC5DDDAA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <8ad71be30705231430p709690c2j17b7706c57b7b992@mail.gmail.com> <7AD436E4270DD54A94238001769C222791BC5DDDAA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <8ad71be30705231539l422acaa9l9b04eac90a7447da@mail.gmail.com> On 5/23/07, Dino Viehland wrote: > We don't yet support defining attributes from Python. It's a common feature request. > > For that you'll need to go to a static language like C# :(. > > I'm not so interested in defining attributes as applying them. My C# book says attributes are just metadata, inspectable by using reflection. It also suggests that you can programmatically modify metadata. Is it possible to use reflection to apply these attributes as necessary? I realize that it would be a bit ugly, but I'm especially interested in doing COM interop stuff with IronPython. Also, I'm having a bit of trouble figuring out how to strongname an IronPython assembly created using pyc.py. Is there any way to do this? I'm not necessarily looking for syntactic sugar using decorators or anything... just looking for a way to get it done. The sugar will come later. -Ben From christian.muirhead at resolversystems.com Thu May 24 15:11:14 2007 From: christian.muirhead at resolversystems.com (Christian Muirhead) Date: Thu, 24 May 2007 14:11:14 +0100 Subject: [IronPython] Excel events from IronPython? Message-ID: <46558EF2.2000806@resolversystems.com> Hi - I'm automating Excel from IP, which has been a bit painful, but looks to be working now. One extra thing I'd like to do is to subscribe to a worksheet's change event. This (http://support.microsoft.com/kb/302815/) is an article that does in C# essentially what I'd like to do in IP. I can construct an AppEvents_SheetChangeEventHandler delegate wrapped around a function, but I can't find the event to hook it up - there's no .Change event on the worksheet. Nosing around the Microsoft.Office.Interop.Excel namespace (the Excel object model documentation is pretty patchy, although I've looked there too), I can see a type called AppEvents_Event, which does seem to expose the events I want. But I can't work out how to instantiate it (or even whether I should be trying to), and trying to attach the delegate to the event on the type results in: >>> Excel.AppEvents_Event.SheetChange += Excel.AppEvents_SheetChangeEventHandler(func) Traceback (most recent call last): File , line 0, in ##165 StandardError: Non-static method requires a target. (Which is pretty clear.) I'm about to try following the example in C#, and hopefully I'll be able to work out what the C# code's doing differently. In the meantime, has anyone successfully consumed Excel (or any Office application) events in IronPython? Can anyone familiar with COM<->.NET interop see what I should be doing? Thanks, Christian -- Christian Muirhead Resolver Systems christian.muirhead at resolversystems.com Office address: 17a Clerkenwell Road, London EC1M 5RD, UK Registered address: 843 Finchley Road, London NW11 8NA, UK Resolver Systems Limited is registered in England and Wales as company number 5467329. VAT No. GB 893 5643 79 From dinov at exchange.microsoft.com Thu May 24 17:52:19 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 24 May 2007 08:52:19 -0700 Subject: [IronPython] how to apply guid In-Reply-To: <8ad71be30705231539l422acaa9l9b04eac90a7447da@mail.gmail.com> References: <8ad71be30705231430p709690c2j17b7706c57b7b992@mail.gmail.com> <7AD436E4270DD54A94238001769C222791BC5DDDAA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <8ad71be30705231539l422acaa9l9b04eac90a7447da@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DDEB2@DF-GRTDANE-MSG.exchange.corp.microsoft.com> If you really just want a way to get it done that way is via Reflection.Emit. Either you can do it all via RefEmit and ignore creating classes from Python or you can try and cooperate w/ IronPython and extend a Python class so it has attributes. The former I'll leave to the RefEmit documentation (or classes like NewTypeMaker in the IronPython code base). For the latter the most important thing to understand is what happens when you do: class xyz(object): pass in IronPython. We create a new type, IronPython.Runtime.NewTypes.System.Object_# where # is an ever-increasing number for each class created. We override all the virtual methods and add a new ctor: Object_#(UserType type); The argument there becomes the __class__ field which the user can change at runtime. Therefore what you'd want to do is first define a class in Python, create an instance of it, then call .GetType() to get its type. From there you could derive from that type adding any attributes you wanted. Then you could create instances of it by calling the new type and passing in a type object. You can probably simply that latter part by poking around at UserType (in v1.x) and DynamicType (in v2.x) so that you can easily create the type. Alternately when you create the new subtype you can have it always call the base ctor w/ your previously created UserType instance. That's probably no small amount of work but that's how you could do it. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Benjamin West Sent: Wednesday, May 23, 2007 3:40 PM To: Discussion of IronPython Subject: Re: [IronPython] how to apply guid On 5/23/07, Dino Viehland wrote: > We don't yet support defining attributes from Python. It's a common feature request. > > For that you'll need to go to a static language like C# :(. > > I'm not so interested in defining attributes as applying them. My C# book says attributes are just metadata, inspectable by using reflection. It also suggests that you can programmatically modify metadata. Is it possible to use reflection to apply these attributes as necessary? I realize that it would be a bit ugly, but I'm especially interested in doing COM interop stuff with IronPython. Also, I'm having a bit of trouble figuring out how to strongname an IronPython assembly created using pyc.py. Is there any way to do this? I'm not necessarily looking for syntactic sugar using decorators or anything... just looking for a way to get it done. The sugar will come later. -Ben _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at exchange.microsoft.com Thu May 24 18:16:28 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 24 May 2007 09:16:28 -0700 Subject: [IronPython] PythonEngine in separate AppDomain? In-Reply-To: <64B0479F895F194587EE70276364C5C6028A223F@wcosmb02.cos.agilent.com> References: <64B0479F895F194587EE70276364C5C6028A1E7F@wcosmb02.cos.agilent.com> <7AD436E4270DD54A94238001769C222791BC5DDB40@DF-GRTDANE-MSG.exchange.corp.microsoft.com> <64B0479F895F194587EE70276364C5C6028A223F@wcosmb02.cos.agilent.com> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DDEC8@DF-GRTDANE-MSG.exchange.corp.microsoft.com> The only change I had to make to get your simple sample code to work was change PythonInstance to derive from MarshalByRefObject. I wonder if typeof(Program).Assembly.Location could end up pointing to a location which is not fully trusted (e.g. a network share?) It seems highly unlikely but it's the only explanation I can come up with (.NET determines what level of trust to grant assemblies based upon what zone the code came from - where the zone is the same zones that IE uses). using System; using System.Collections.Generic; using System.Text; using System.IO; using System.Reflection; using IronPython.Hosting; using IronPython.Runtime; using IronPython.Runtime.Operations; using IronPython.Modules; namespace ConsoleApplication1 { [Serializable] public class PythonInstance : MarshalByRefObject { // IronPython Modules private static PythonEngine _python; public PythonInstance() { // Create Python Engine EngineOptions options = new EngineOptions(); options.ExceptionDetail = true; options.ClrDebuggingEnabled = true; PythonInstance._python = new PythonEngine(options); } public void AddPythonPath(string path) { PythonInstance._python.AddToPath(path); } } class Program { static void Main(string[] args) { AppDomainSetup setup = new AppDomainSetup(); setup.ApplicationName = Assembly.GetEntryAssembly().FullName; setup.ApplicationBase = Path.GetDirectoryName(typeof(Program).Assembly.Location); AppDomain domain = AppDomain.CreateDomain("PythonDomain", null, setup); // Create Test Engine in remote domain object obj = domain.CreateInstanceAndUnwrap("ConsoleApplication1", "ConsoleApplication1.PythonInstance"); PythonInstance python = obj as PythonInstance; python.AddPythonPath(@"C:\temp"); } } } From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of michael_sweeney at agilent.com Sent: Wednesday, May 23, 2007 9:22 AM To: users at lists.ironpython.com Subject: Re: [IronPython] PythonEngine in separate AppDomain? Hi Dino, I get this error with or without the permission code. Here is the problem I am trying to solve... We have a test tool that allows the load/reload of Python test scripts. It is implemented in CPython. We manipulate the sys.modules dictionary to "clean" out any modules the test module loaded. This "cleaning" allows the developers to quickly run/edit/reload/run the test scripts. We are porting this application to IronPython by hosting the PythonEngine in a C# application. The new tool allows the user to load .NET assemblies as well as the classic python modules. The ability to reload is handy. Since it is possible to unload AppDomains for the assembly based tests, I was thinking that just putting the PythonEngine in a separate AppDomain I could handle the unload the same way. This is when I started running into permission issues. I wanted to avoid the "cleaning" of the sys.modules dictionary because it has proved error-prone in the CPython implementation. I may have to start going down this path. Thanks for your feedback. Mike From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, May 22, 2007 1:54 PM To: Discussion of IronPython Subject: Re: [IronPython] PythonEngine in separate AppDomain? Are you getting this even if you don't do anything w/ permissions? You're going to have a tough time running IronPython in partial trust before .NET 2.0 SP1 or Orcas. In SP1 of the CLR (which is the CLR included w/ Orcas and I believe will ship stand-alone as its own SP at some point) various portions of Reflection.Emit have had the appropriate security hardening to ensure they work properly in partial trust. Unfortunately both of those are still beta code :(. Thanks in advance... Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Thu May 24 18:28:12 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 24 May 2007 09:28:12 -0700 Subject: [IronPython] Problem stepping into functions in debugger with F11 In-Reply-To: <919035ab0705231304u30f31f3fta587a63f35ffcd66@mail.gmail.com> References: <919035ab0705231304u30f31f3fta587a63f35ffcd66@mail.gmail.com> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DDECF@DF-GRTDANE-MSG.exchange.corp.microsoft.com> This looks like a bug - the issue here is that there's a section of code right after the method prologue which is not associated with any source information (see below to see the raw details). Luckily we have a command line switch which will get rid of the extra info and make stepping work for you again, and that's -X:NoTraceback (the extra instructions are marking line number info so we can extract it back out at runtime). The ultimate result of that switch is that exec'd code will be missing Python line number information. In v2.0 we have gotten much more serious about getting the debugging experience 100% right. We're starting to bring on test suites to ensure that all of our debugging information is emitted correctly, that we step through the various control flow blocks in a reasonable way, etc... In v1.x we do an alright job but we haven't dedicated the test resources to ensure it's a great experience. Because of that I'm inclined to not open a bug on this and just say the experience will be much better in v2.0. Let me know if you think that's the wrong call :). 00000000 push ebp 00000001 mov ebp,esp 00000003 push edi 00000004 push esi 00000005 push ebx 00000006 sub esp,2Ch 00000009 xor eax,eax 0000000b mov dword ptr [ebp-24h],eax 0000000e mov dword ptr [ebp-28h],eax 00000011 mov dword ptr [ebp-38h],eax 00000014 xor eax,eax 00000016 mov dword ptr [ebp-18h],eax 00000019 mov dword ptr [ebp-30h],ecx 0000001c mov dword ptr [ebp-34h],edx 0000001f cmp dword ptr ds:[036132FCh],0 00000026 je 0000002D 00000028 call 76A35C56 0000002d xor edx,edx 0000002f mov dword ptr [ebp-2Ch],edx 00000032 xor edx,edx 00000034 mov dword ptr [ebp-38h],edx 00000037 mov dword ptr [ebp-28h],0 From dinov at exchange.microsoft.com Thu May 24 19:44:33 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 24 May 2007 10:44:33 -0700 Subject: [IronPython] Excel events from IronPython? In-Reply-To: <46558EF2.2000806@resolversystems.com> References: <46558EF2.2000806@resolversystems.com> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DDF03@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I think this is what you want: import clr clr.AddReferenceByName('Microsoft.Office.Interop.Excel, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c') import Microsoft.Office.Interop.Excel as Excel ex = Excel.ApplicationClass() from System.Reflection import Missing xlBook = ex.Workbooks.Add( Missing.Value ) xlSheet1 = xlBook.Worksheets[1] xlSheet1.Activate() def foo(*args): print args Excel.DocEvents_Event.add_Change(xlSheet1, foo) This is a really odd way to do this but there's multiple types we can find that are associated with the COM object. Currently we're picking just one of the COM interfaces which is supported on the object so to use the other interfaces you need to call directly through the interface. In this case if you look at the Worksheet class in MS.Office.Interop.Excel you'll see it implements: MS.Office.Interop.Excel_Worksheet MS.Office.Interop.Excel.DocEvents_Event We're picking _Worksheet as the interface type instead of Worksheet. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Christian Muirhead Sent: Thursday, May 24, 2007 6:11 AM To: Discussion of IronPython Subject: [IronPython] Excel events from IronPython? Hi - I'm automating Excel from IP, which has been a bit painful, but looks to be working now. One extra thing I'd like to do is to subscribe to a worksheet's change event. This (http://support.microsoft.com/kb/302815/) is an article that does in C# essentially what I'd like to do in IP. I can construct an AppEvents_SheetChangeEventHandler delegate wrapped around a function, but I can't find the event to hook it up - there's no .Change event on the worksheet. Nosing around the Microsoft.Office.Interop.Excel namespace (the Excel object model documentation is pretty patchy, although I've looked there too), I can see a type called AppEvents_Event, which does seem to expose the events I want. But I can't work out how to instantiate it (or even whether I should be trying to), and trying to attach the delegate to the event on the type results in: >>> Excel.AppEvents_Event.SheetChange += Excel.AppEvents_SheetChangeEventHandler(func) Traceback (most recent call last): File , line 0, in ##165 StandardError: Non-static method requires a target. (Which is pretty clear.) I'm about to try following the example in C#, and hopefully I'll be able to work out what the C# code's doing differently. In the meantime, has anyone successfully consumed Excel (or any Office application) events in IronPython? Can anyone familiar with COM<->.NET interop see what I should be doing? Thanks, Christian -- Christian Muirhead Resolver Systems christian.muirhead at resolversystems.com Office address: 17a Clerkenwell Road, London EC1M 5RD, UK Registered address: 843 Finchley Road, London NW11 8NA, UK Resolver Systems Limited is registered in England and Wales as company number 5467329. VAT No. GB 893 5643 79 _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From julien.couvreur at gmail.com Thu May 24 22:10:34 2007 From: julien.couvreur at gmail.com (Julien Couvreur) Date: Thu, 24 May 2007 13:10:34 -0700 Subject: [IronPython] Problem stepping into functions in debugger with F11 In-Reply-To: <7AD436E4270DD54A94238001769C222791BC5DDECF@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <919035ab0705231304u30f31f3fta587a63f35ffcd66@mail.gmail.com> <7AD436E4270DD54A94238001769C222791BC5DDECF@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <919035ab0705241310i1ba44a6cqd962d1fafda54afb@mail.gmail.com> Thanks a lot for the help. This command-line switch works for me. There doesn't seem to be any negative side effects of this switch as far as I can tell, so I'm happy with this solution until v2.0 comes around ;-) Thanks again, Julien Couvreur http://blog.monstuff.com On 5/24/07, Dino Viehland wrote: > > This looks like a bug ? the issue here is that there's a section of code > right after the method prologue which is not associated with any source > information (see below to see the raw details). Luckily we have a command > line switch which will get rid of the extra info and make stepping work for > you again, and that's ?X:NoTraceback (the extra instructions are marking > line number info so we can extract it back out at runtime). The ultimate > result of that switch is that exec'd code will be missing Python line number > information. > > > > In v2.0 we have gotten much more serious about getting the debugging > experience 100% right. We're starting to bring on test suites to ensure > that all of our debugging information is emitted correctly, that we step > through the various control flow blocks in a reasonable way, etc? In v1.xwe do an alright job but we haven't dedicated the test resources to ensure > it's a great experience. Because of that I'm inclined to not open a bug on > this and just say the experience will be much better in v2.0. Let me know > if you think that's the wrong call J. > > > > 00000000 push ebp > > 00000001 mov ebp,esp > > 00000003 push edi > > 00000004 push esi > > 00000005 push ebx > > 00000006 sub esp,2Ch > > 00000009 xor eax,eax > > 0000000b mov dword ptr [ebp-24h],eax > > 0000000e mov dword ptr [ebp-28h],eax > > 00000011 mov dword ptr [ebp-38h],eax > > 00000014 xor eax,eax > > 00000016 mov dword ptr [ebp-18h],eax > > 00000019 mov dword ptr [ebp-30h],ecx > > 0000001c mov dword ptr [ebp-34h],edx > > 0000001f cmp dword ptr ds:[036132FCh],0 > > 00000026 je 0000002D > > 00000028 call 76A35C56 > > 0000002d xor edx,edx > > 0000002f mov dword ptr [ebp-2Ch],edx > > 00000032 xor edx,edx > > 00000034 mov dword ptr [ebp-38h],edx > > 00000037 mov dword ptr [ebp-28h],0 in here > > 0000003e mov dword ptr [ebp-2Ch],2 ends up here > > --- C:\Product\Released\IronPython-1.1\debugger.py----------------------------- > > def add(a,b): > > return a+b > > 00000045 nop and we're in the function > > 00000046 mov edx,dword ptr [ebp-34h] > > 00000049 mov ecx,dword ptr [ebp-30h] > > 0000004c call dword ptr ds:[001C9150h] > > 00000052 mov esi,eax > > > > > > > > *From:* users-bounces at lists.ironpython.com[mailto: > users-bounces at lists.ironpython.com] > *On Behalf Of *Julien Couvreur > *Sent:* Wednesday, May 23, 2007 1:04 PM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Problem stepping into functions in debugger with > F11 > > > > Hi, > > I'm running a simple program below. I'm trying to "step into" the "add" > function. But Visual Studio 2005 and the Microsoft CLR Debugger (from the > .Net 2.0 SDK) both complain that: > > "There is no source code available for the current location." > > > > They then offer me to view the disassembly. > Any ideas how to fix this? > > > Note that I do have "Enable Just My Code" turned on (which is the > default). > > Thanks, > Julien Couvreur > http://blog.monstuff.com > > > > Repro steps: > 1) save the code below to debugger.ipy > 2) Run ipy.exe debugger.ipy > 3) You should get a prompt to start debugging the code with your favorite > debugger, accept it > 4) The code should be stopped at the breakpoint, you can step forward with > F10 and then F11 > 5) Trying to step into the call to the "add" method fails as described > above > > def add(a,b): > return a+b > > import System.Diagnostics > System.Diagnostics.Debugger.Break() > > print add(4, 4) > > > _______________________________________________ > 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 filipejps at gmail.com Fri May 25 01:26:54 2007 From: filipejps at gmail.com (Filipe Silva) Date: Fri, 25 May 2007 00:26:54 +0100 Subject: [IronPython] Casting python list type to NET type Message-ID: <46a168490705241626v49951b4asb5fe96aa1e8939f7@mail.gmail.com> Hi all, I've an VB.NET application invoking some python functions and I would like these functions to return a list type. I've already tried to cast the result from "list" (python) to Collection (VB.NET), also to ArrayList and to a simple string array. In all cases I receive a cast exception saying that it's not possible to make that conversion... Is there any NET type that could be directly casted from ironpython list type? Note: 1. I can return a String instead of a list, but I would need to parse that string inside VB.NET (using some kind of token) 2. I've found a solution by importing System.Collections.ArrayList in my python script, then using ArrayList object instead of native list type, however this way, my script doesn't work in a different engine (that one in www.python.org, for instance) Thanks, Filipe From fuzzyman at voidspace.org.uk Fri May 25 01:35:12 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 25 May 2007 00:35:12 +0100 Subject: [IronPython] Casting python list type to NET type In-Reply-To: <46a168490705241626v49951b4asb5fe96aa1e8939f7@mail.gmail.com> References: <46a168490705241626v49951b4asb5fe96aa1e8939f7@mail.gmail.com> Message-ID: <46562130.1020402@voidspace.org.uk> Filipe Silva wrote: > Hi all, > > I've an VB.NET application invoking some python functions and I would > like these functions to return a list type. > To use the return values from other .NET languages like VB.NET and C# I think you have little choice but to use a .NET collection. You could make this conditional by wrapping the import in a 'try.. except' and having different behaviour on platforms where the .NET type is not available (i.e. CPython). Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml > I've already tried to cast the result from "list" (python) to > Collection (VB.NET), also to ArrayList and to a simple string array. > In all cases I receive a cast exception saying that it's not possible > to make that conversion... > > Is there any NET type that could be directly casted from ironpython list type? > > Note: > 1. I can return a String instead of a list, but I would need to parse > that string inside VB.NET (using some kind of token) > > 2. I've found a solution by importing System.Collections.ArrayList in > my python script, then using ArrayList object instead of native list > type, however this way, my script doesn't work in a different engine > (that one in www.python.org, for instance) > > > Thanks, > Filipe > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From sanxiyn at gmail.com Fri May 25 03:29:59 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Fri, 25 May 2007 10:29:59 +0900 Subject: [IronPython] Casting python list type to NET type In-Reply-To: <46562130.1020402@voidspace.org.uk> References: <46a168490705241626v49951b4asb5fe96aa1e8939f7@mail.gmail.com> <46562130.1020402@voidspace.org.uk> Message-ID: <5b0248170705241829q2a3c28e7qc0a4883c45ec9852@mail.gmail.com> 2007/5/25, Michael Foord : > You could make this conditional by wrapping the import in a 'try.. > except' and having different behaviour on platforms where the .NET type > is not available (i.e. CPython). Or, check sys.platform. If you intend to run the same code on both CPython and IronPython, and if you want some section of code to run only on IronPython, the best way I found is: if sys.platform == 'cli': # IronPython specific -- Seo Sanghyeon From dinov at exchange.microsoft.com Fri May 25 03:39:04 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Thu, 24 May 2007 18:39:04 -0700 Subject: [IronPython] Casting python list type to NET type In-Reply-To: <46562130.1020402@voidspace.org.uk> References: <46a168490705241626v49951b4asb5fe96aa1e8939f7@mail.gmail.com> <46562130.1020402@voidspace.org.uk> Message-ID: <7AD436E4270DD54A94238001769C222791BC5DE02C@DF-GRTDANE-MSG.exchange.corp.microsoft.com> I'll also add if it's your own application you should be coding to receive IList or IList instead of List. Typically they'll have everything you need and accept a wider range of inputs - e.g. arrays, LinkedList's, normal List's, etc... And if you can get away with it maybe just IEnumerable. Of course if it's someone else's app that's of no use :(. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, May 24, 2007 4:35 PM To: Discussion of IronPython Subject: Re: [IronPython] Casting python list type to NET type Filipe Silva wrote: > Hi all, > > I've an VB.NET application invoking some python functions and I would > like these functions to return a list type. > To use the return values from other .NET languages like VB.NET and C# I think you have little choice but to use a .NET collection. You could make this conditional by wrapping the import in a 'try.. except' and having different behaviour on platforms where the .NET type is not available (i.e. CPython). Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml > I've already tried to cast the result from "list" (python) to > Collection (VB.NET), also to ArrayList and to a simple string array. > In all cases I receive a cast exception saying that it's not possible > to make that conversion... > > Is there any NET type that could be directly casted from ironpython list type? > > Note: > 1. I can return a String instead of a list, but I would need to parse > that string inside VB.NET (using some kind of token) > > 2. I've found a solution by importing System.Collections.ArrayList in > my python script, then using ArrayList object instead of native list > type, however this way, my script doesn't work in a different engine > (that one in www.python.org, for instance) > > > Thanks, > Filipe > _______________________________________________ > 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 christian.muirhead at resolversystems.com Fri May 25 16:39:07 2007 From: christian.muirhead at resolversystems.com (Christian Muirhead) Date: Fri, 25 May 2007 15:39:07 +0100 Subject: [IronPython] Excel events from IronPython? In-Reply-To: <7AD436E4270DD54A94238001769C222791BC5DDF03@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <46558EF2.2000806@resolversystems.com> <7AD436E4270DD54A94238001769C222791BC5DDF03@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <4656F50B.2070306@resolversystems.com> Thanks Dino - This is exactly what I needed. I found two articles that talk a bit about what is happening behind the scenes here (although they're more focused on providing .NET functionality to COM code, rather than the other way), if anyone else is interested. http://www.15seconds.com/issue/040721.htm http://www.15seconds.com/issue/060309.htm Cheers, Christian Dino Viehland wrote: > I think this is what you want: > > import clr > clr.AddReferenceByName('Microsoft.Office.Interop.Excel, Version=11.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c') > import Microsoft.Office.Interop.Excel as Excel > ex = Excel.ApplicationClass() > from System.Reflection import Missing > xlBook = ex.Workbooks.Add( Missing.Value ) > > xlSheet1 = xlBook.Worksheets[1] > xlSheet1.Activate() > > def foo(*args): print args > > Excel.DocEvents_Event.add_Change(xlSheet1, foo) > > > This is a really odd way to do this but there's multiple types we can find that are associated with the COM object. Currently we're picking just one of the COM interfaces which is supported on the object so to use the other interfaces you need to call directly through the interface. > > In this case if you look at the Worksheet class in MS.Office.Interop.Excel you'll see it implements: > > MS.Office.Interop.Excel_Worksheet > MS.Office.Interop.Excel.DocEvents_Event > > We're picking _Worksheet as the interface type instead of Worksheet. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Christian Muirhead > Sent: Thursday, May 24, 2007 6:11 AM > To: Discussion of IronPython > Subject: [IronPython] Excel events from IronPython? > > Hi - > > I'm automating Excel from IP, which has been a bit painful, but looks to > be working now. One extra thing I'd like to do is to subscribe to a > worksheet's change event. > > This (http://support.microsoft.com/kb/302815/) is an article that does > in C# essentially what I'd like to do in IP. I can construct an > AppEvents_SheetChangeEventHandler delegate wrapped around a function, > but I can't find the event to hook it up - there's no .Change event on > the worksheet. > > Nosing around the Microsoft.Office.Interop.Excel namespace (the Excel > object model documentation is pretty patchy, although I've looked there > too), I can see a type called AppEvents_Event, which does seem to expose > the events I want. But I can't work out how to instantiate it (or even > whether I should be trying to), and trying to attach the delegate to the > event on the type results in: > > >>> Excel.AppEvents_Event.SheetChange += > Excel.AppEvents_SheetChangeEventHandler(func) > Traceback (most recent call last): > File , line 0, in ##165 > StandardError: Non-static method requires a target. > > (Which is pretty clear.) > > I'm about to try following the example in C#, and hopefully I'll be able > to work out what the C# code's doing differently. > > In the meantime, has anyone successfully consumed Excel (or any Office > application) events in IronPython? Can anyone familiar with COM<->.NET > interop see what I should be doing? > > Thanks, > Christian > > -- > Christian Muirhead > Resolver Systems > christian.muirhead at resolversystems.com > > Office address: 17a Clerkenwell Road, London EC1M 5RD, UK > Registered address: 843 Finchley Road, London NW11 8NA, UK > > Resolver Systems Limited is registered in England and Wales as company > number 5467329. > VAT No. GB 893 5643 79 > _______________________________________________ > 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 -- Christian Muirhead Resolver Systems christian.muirhead at resolversystems.com Office address: 17a Clerkenwell Road, London EC1M 5RD, UK Registered address: 843 Finchley Road, London NW11 8NA, UK Resolver Systems Limited is registered in England and Wales as company number 5467329. VAT No. GB 893 5643 79 From Mahesh.Prakriya at microsoft.com Sat May 26 02:00:03 2007 From: Mahesh.Prakriya at microsoft.com (Mahesh Prakriya) Date: Fri, 25 May 2007 17:00:03 -0700 Subject: [IronPython] Our talks at Teched 2007 (June 4-8th) in Orlando Message-ID: <8DD6D7B47848B24F972C23F274C6E568091F5D62A4@NA-EXMSG-C112.redmond.corp.microsoft.com> Are posted at: http://blogs.msdn.com/ironpython/archive/2007/05/25/our-talks-at-teched-2007-june-4-8th-in-orlando.aspx Check them out. Hope you can join us there! Mahesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From hieristda at gmx.de Sun May 27 13:34:33 2007 From: hieristda at gmx.de (hieristda at gmx.de) Date: Sun, 27 May 2007 13:34:33 +0200 Subject: [IronPython] Implement Abstract Class and Interface Message-ID: <20070527113433.219900@gmx.net> Hello, i want to implement an abstract class and an interface in ironpython but it does not work. Here is a code sample. class IronPythonSample(MarshalByRefObject, MyInterface): "Description of Class" var= None def getName(self): return "Iron Python Sample" def ..... I implement all needed methods and i can compile the file. But the resulting exe does not serializable and does not implement MyInterface. I have seen this in the ObjectBrowser of Visual Studio. Is it not possible to implement abstract classes and interfaces in IronPython? MyInterface is implemented in C#. Thanks Maik PS I used the Microsoft Visual Studio 2005 (with IronPython Addin). -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser From davidjensen at usa.net Sun May 27 14:05:17 2007 From: davidjensen at usa.net (David Jensen) Date: Sun, 27 May 2007 08:05:17 -0400 Subject: [IronPython] users Digest, Vol 34, Issue 34 Message-ID: <143LeAmeR5486S29.1180267517@cmsweb29.cms.usa.net> It would be nice if these were put on-demnand on Microsoft's site. ------ Original Message ------ Received: Sat, 26 May 2007 07:15:42 PM EDT From: users-request at lists.ironpython.com To: users at lists.ironpython.com Subject: users Digest, Vol 34, Issue 34 > Send users mailing list submissions to > users at lists.ironpython.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > or, via email, send a message with subject or body 'help' to > users-request at lists.ironpython.com > > You can reach the person managing the list at > users-owner at lists.ironpython.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of users digest..." > > > Today's Topics: > > 1. Our talks at Teched 2007 (June 4-8th) in Orlando (Mahesh Prakriya) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 25 May 2007 17:00:03 -0700 > From: Mahesh Prakriya > Subject: [IronPython] Our talks at Teched 2007 (June 4-8th) in Orlando > To: "users at lists.ironpython.com" > Message-ID: > <8DD6D7B47848B24F972C23F274C6E568091F5D62A4 at NA-EXMSG-C112.redmond.corp.microsoft.com> > > Content-Type: text/plain; charset="us-ascii" > > Are posted at: > > http://blogs.msdn.com/ironpython/archive/2007/05/25/our-talks-at-teched-2007-june-4-8th-in-orlando.aspx > > Check them out. Hope you can join us there! > > Mahesh > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.ironpython.com/pipermail/users-ironpython.com/attachments/20070525/f06feac7/attachment-0001.html > > ------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > End of users Digest, Vol 34, Issue 34 > ************************************* > From sanxiyn at gmail.com Mon May 28 08:57:13 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Mon, 28 May 2007 15:57:13 +0900 Subject: [IronPython] Missing func_closure Message-ID: <5b0248170705272357p272c4e38q5261271b78b6c6ba@mail.gmail.com> IronPython function objects are missing func_closure attribute. This is hit by decorator module which tries to clone the function object. http://cheeseshop.python.org/pypi/decorator -- Seo Sanghyeon From anthony_raj at persistent.co.in Mon May 28 12:53:44 2007 From: anthony_raj at persistent.co.in (Anthony Raj) Date: Mon, 28 May 2007 16:23:44 +0530 Subject: [IronPython] Error while porting Linux code to IronPython Message-ID: Hi All, Currently have an error while porting code from Linux to Windows environment. We have the code working as web calls on linux. Now we're trying to do a performance analysis of the same code running on windows using ironpython. Basically we are trying to integrate our linux product with a Windows counterpart and facing some errors in the Python code. The error is in the class having global variables defined - >>> class parser: leafNodesDict = dict() usedInNodesDict = dict() requiredNodesDict = dict() optionalNodesDict = dict() >>> C:\IronPython-1.1>ipy.exe Lib/ast/parser.py Traceback (most recent call last): File C:\IronPython-1.1\Lib\ast\parser.py, line 36, in Initialize File C:\IronPython-1.1\Lib\ast\parser.py, line 37, in parser TypeError: Dictionary object is not callable Now line 37 is "leafNodesDict = dict()" The same code works perfectly in linux. Tried moving the global variables inside def __init__() method. It still breaks with the same error. Another point - the error is the same when run using CPython. Iron Python Version C:\IronPython-1.1>ipy.exe IronPython 1.1 (1.1) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> CPython Version C:\IronPython-1.1>ipy.exe IronPython 1.1 (1.1) on .NET 2.0.50727.42 Copyright (c) Microsoft Corporation. All rights reserved. >>> Some pointers would be very helpful. TIA, Anthony DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon May 28 13:11:56 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 28 May 2007 12:11:56 +0100 Subject: [IronPython] Error while porting Linux code to IronPython In-Reply-To: References: Message-ID: <465AB8FC.7090508@voidspace.org.uk> Anthony Raj wrote: > > Hi All, > > Currently have an error while porting code from Linux to Windows > environment. > > We have the code working as web calls on linux. Now we?re trying to do > a performance > > analysis of the same code running on windows using ironpython. > > Basically we are trying to integrate our linux product with a Windows > counterpart and > > facing some errors in the Python code. > > The error is in the class having global variables defined ? > > >>> > > class parser: > > leafNodesDict = dict() > > usedInNodesDict = dict() > > requiredNodesDict = dict() > > optionalNodesDict = dict() > > >>> > Hello Anthony, The code you have posted works fine for me. The error would indicate that somewhere in your code you have redefined 'dict' by using it as a variable name. Try replacing them with dict literals - {}. If the problem goes away then that is probably the problem. Michael http://www.voidspace.org.uk/ironpython/index.shtml > C:\IronPython-1.1>ipy.exe Lib/ast/parser.py > > Traceback (most recent call last): > > File C:\IronPython-1.1\Lib\ast\parser.py, line 36, in Initialize > > File C:\IronPython-1.1\Lib\ast\parser.py, line 37, in parser > > TypeError: Dictionary object is not callable > > Now line 37 is ?leafNodesDict = dict()? > > The same code works perfectly in linux. > > Tried moving the global variables inside def __init__() method. > > It still breaks with the same error. > > Another point ? the error is the same when run using CPython. > > Iron Python Version > > C:\IronPython-1.1>ipy.exe > > IronPython 1.1 (1.1) on .NET 2.0.50727.42 > > Copyright (c) Microsoft Corporation. All rights reserved. > > >>> > > CPython Version > > C:\IronPython-1.1>ipy.exe > > IronPython 1.1 (1.1) on .NET 2.0.50727.42 > > Copyright (c) Microsoft Corporation. All rights reserved. > > >>> > > Some pointers would be very helpful. > > TIA, > > Anthony > > DISCLAIMER ========== This e-mail may contain privileged and > confidential information which is the property of Persistent Systems > Pvt. Ltd. It is intended only for the use of the individual or entity > to which it is addressed. If you are not the intended recipient, you > are not authorized to read, retain, copy, print, distribute or use > this message. If you have received this communication in error, please > notify the sender and delete all copies of this message. Persistent > Systems Pvt. Ltd. does not accept any liability for virus infected mails. > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From anthony_raj at persistent.co.in Mon May 28 14:41:56 2007 From: anthony_raj at persistent.co.in (Anthony Raj) Date: Mon, 28 May 2007 18:11:56 +0530 Subject: [IronPython] Error while porting Linux code to IronPython Message-ID: Hi Micheal, Thanks for your reply. Have changed the declaration from leafNodes = dict to leafNodes = {} and its working now . There are no variable names as dict in the code, which is what puzzles me. You mentioned that the code works for you. True ~ I forgot to mention that it works for me in a hello.py class too. Also the code works as it is in various linux environments. Some how, I have a feeling that dictionary declarations in windows version of CPython and Iron Python has some conflicts with other declarations. Thanks, Anthony DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon May 28 14:46:20 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 28 May 2007 13:46:20 +0100 Subject: [IronPython] Error while porting Linux code to IronPython In-Reply-To: References: Message-ID: <465ACF1C.2050008@voidspace.org.uk> Anthony Raj wrote: > > Hi Micheal, > > > > Thanks for your reply. > > Have changed the declaration from leafNodes = dict to leafNodes = {} > and its working now . > > There are no variable names as dict in the code, which is what puzzles me. > > > You could try putting the old code back, and before the offending line put a 'print dict' in to try and diagnose what the object is. 'dict' is so fundamental to Python that I'm pretty sure it can't be broken like that - something else must be happening. Michael http://www.voidspace.org.uk/ironpython/index.shtml > You mentioned that the code works for you. > > True ~ I forgot to mention that it works for me in a hello.py class too. > > > > Also the code works as it is in various linux environments. > > Some how, I have a feeling that dictionary declarations in windows version > > of CPython and Iron Python has some conflicts with other declarations. > > > > Thanks, > > Anthony > > DISCLAIMER ========== This e-mail may contain privileged and > confidential information which is the property of Persistent Systems > Pvt. Ltd. It is intended only for the use of the individual or entity > to which it is addressed. If you are not the intended recipient, you > are not authorized to read, retain, copy, print, distribute or use > this message. If you have received this communication in error, please > notify the sender and delete all copies of this message. Persistent > Systems Pvt. Ltd. does not accept any liability for virus infected mails. > > ------------------------------------------------------------------------ > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From anthony_raj at persistent.co.in Tue May 29 06:36:42 2007 From: anthony_raj at persistent.co.in (Anthony Raj) Date: Tue, 29 May 2007 10:06:42 +0530 Subject: [IronPython] Error while porting Linux code to IronPython Message-ID: <11829CF927C341B6A6D1370BCB3838B4@persistent.co.in> Hi Micheal, You were right again. Something unexpected turned up. The error was a conflict with the dictionary instance used in Wordnet library for windows. ---- C:\IronPython-1.1>ipy.exe Lib/ast/rbsParser1.py Gotcha -> Traceback (most recent call last): File C:\IronPython-1.1\Lib\ast\rbsParser1.py, line 36, in Initialize File C:\IronPython-1.1\Lib\ast\rbsParser1.py, line 38, in rbsParser TypeError: Dictionary object is not callable ---- Not sure why wordnet had to use dict as a dictionary object. Need to report it to Wordnet developer group. Thanks, Anthony DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. From fuzzyman at voidspace.org.uk Tue May 29 10:23:44 2007 From: fuzzyman at voidspace.org.uk (Fuzzyman) Date: Tue, 29 May 2007 09:23:44 +0100 Subject: [IronPython] Error while porting Linux code to IronPython In-Reply-To: <11829CF927C341B6A6D1370BCB3838B4@persistent.co.in> References: <11829CF927C341B6A6D1370BCB3838B4@persistent.co.in> Message-ID: <465BE310.8090601@voidspace.org.uk> Anthony Raj wrote: >Hi Micheal, > >You were right again. Something unexpected turned up. > >The error was a conflict with the dictionary instance used in >Wordnet library for windows. > > Ah... the joys of "from module import *". :-) Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml >---- >C:\IronPython-1.1>ipy.exe Lib/ast/rbsParser1.py >Gotcha -> >Traceback (most recent call last): > File C:\IronPython-1.1\Lib\ast\rbsParser1.py, line 36, in Initialize > File C:\IronPython-1.1\Lib\ast\rbsParser1.py, line 38, in rbsParser >TypeError: Dictionary object is not callable >---- > >Not sure why wordnet had to use dict as a dictionary object. >Need to report it to Wordnet developer group. > >Thanks, >Anthony > > >DISCLAIMER >========== >This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. >_______________________________________________ >users mailing list >users at lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > From Martin.Maly at microsoft.com Tue May 29 17:13:25 2007 From: Martin.Maly at microsoft.com (Martin Maly) Date: Tue, 29 May 2007 08:13:25 -0700 Subject: [IronPython] Missing func_closure In-Reply-To: <5b0248170705272357p272c4e38q5261271b78b6c6ba@mail.gmail.com> References: <5b0248170705272357p272c4e38q5261271b78b6c6ba@mail.gmail.com> Message-ID: Thanks, Seo, I opened an issue on CodePlex to track this: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=10637 Martin -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Sunday, May 27, 2007 11:57 PM To: Discussion of IronPython Subject: [IronPython] Missing func_closure IronPython function objects are missing func_closure attribute. This is hit by decorator module which tries to clone the function object. http://cheeseshop.python.org/pypi/decorator -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From JohnSzurek at clearchannel.com Wed May 30 03:56:31 2007 From: JohnSzurek at clearchannel.com (Szurek, John) Date: Tue, 29 May 2007 20:56:31 -0500 Subject: [IronPython] Console Message-ID: I'm having a bit of an adjustment in moving from Python to IronPython and hope that somebody can help..... The console in Python is a real Windows window. When I run Python in the Python console I get an output window that is a real Windows window. All of that means that I can cut and paste freely into the code window and I can cut and paste freely from the results window. The IronPython "console" is not a console at all, it is the command line. It is clumsy and clunky and virtually unusable unless you are pre-Windows and happen to like command lines! Kind of ironic, I think --- the open source community builds a language that runs natively in a Windows environment while Microsoft builds an "improvement" on the language that runs at the command line! So, am I missing something here? Thanks --- John -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Wed May 30 04:12:25 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Tue, 29 May 2007 19:12:25 -0700 Subject: [IronPython] Console In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C222791BCBF65CA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Some tweaks to make it better: .\ipy.exe -X:ColorfulConsole -X:TabCompletion -X:AutoIndent Or some combination thereof (I don't like AutoIndent because copy & pasting code breaks). And make sure to enable Quickedit Mode on the console (Right Click menu bar, Properties->Options->Quick Edit Mode) and fix the default buffer size. Console, command line? I've always considered these to be basically the same. If you were expecting a light weight IDE app or something - well, we don't really have one of those yet. At best we have the VS SDK integration sample which includes IDE & WinForms drag&drop support - but it is a sample and requires VS Pro. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Szurek, John Sent: Tuesday, May 29, 2007 6:57 PM To: users at lists.ironpython.com Subject: [IronPython] Console I'm having a bit of an adjustment in moving from Python to IronPython and hope that somebody can help..... The console in Python is a real Windows window. When I run Python in the Python console I get an output window that is a real Windows window. All of that means that I can cut and paste freely into the code window and I can cut and paste freely from the results window. The IronPython "console" is not a console at all, it is the command line. It is clumsy and clunky and virtually unusable unless you are pre-Windows and happen to like command lines! Kind of ironic, I think --- the open source community builds a language that runs natively in a Windows environment while Microsoft builds an "improvement" on the language that runs at the command line! So, am I missing something here? Thanks --- John -------------- next part -------------- An HTML attachment was scrubbed... URL: From daftspaniel at gmail.com Wed May 30 09:40:49 2007 From: daftspaniel at gmail.com (Davy Mitchell) Date: Wed, 30 May 2007 08:40:49 +0100 Subject: [IronPython] Console In-Reply-To: <7AD436E4270DD54A94238001769C222791BCBF65CA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222791BCBF65CA@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <20253b0c0705300040u539e09ach2343fe9fa557ae18@mail.gmail.com> For something a bit better than cmd, try http://sourceforge.net/projects/console Tabs, improve text selection, transparency and more. Cheers, Davy -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel needgod.com From unrealportal at gmail.com Wed May 30 12:38:21 2007 From: unrealportal at gmail.com (unrealportal) Date: Wed, 30 May 2007 12:38:21 +0200 Subject: [IronPython] Console In-Reply-To: References: Message-ID: <742ac5140705300338p1ff241et62c70d017b1963ba@mail.gmail.com> Try taking a look at IPIDE at http://lynanda.com/mediawiki/index.php/Main_Page. I can't say this on behalf of Microsoft, but I am sure that the command line window is just a quick way to have an interface to IronPython. I wouldn't be concerned about this being the intended way to use IronPython on daily basis. Regards, On 5/30/07, Szurek, John wrote: > > I'm having a bit of an adjustment in moving from Python to IronPython and > hope that somebody can help?.. > > > > The console in Python is a real Windows window. When I run Python in the > Python console I get an output window that is a real Windows window. All of > that means that I can cut and paste freely into the code window and I can > cut and paste freely from the results window. The IronPython "console" is > not a console at all, it is the command line. It is clumsy and clunky and > virtually unusable unless you are pre-Windows and happen to like command > lines! Kind of ironic, I think --- the open source community builds a > language that runs natively in a Windows environment while Microsoft builds > an "improvement" on the language that runs at the command line! > > > > So, am I missing something here? Thanks --- John > > _______________________________________________ > 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 ygutfreund at draper.com Wed May 30 15:19:28 2007 From: ygutfreund at draper.com (Gutfreund, Yechezkal) Date: Wed, 30 May 2007 09:19:28 -0400 Subject: [IronPython] console Message-ID: <98B94F0758D7394CA057AE4898CBC85E04664898@exchbk1.draper.com> What can I say, I like the PowerShell. It would be nice if we could merge that on the bottom, with a simple source editor (like NotePad++) on the top. I would consider that a vey powerful light-weight IDE. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Dr. Yechezkal Gutfreund Tactical ISR Division Draper Laboratories 555 Technology Square Cambridge, MA 02139 +1-617-258-4206 ygutfreund at draper.com =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Wed May 30 18:00:13 2007 From: fuzzyman at voidspace.org.uk (fuzzyman at voidspace.org.uk) Date: Wed, 30 May 2007 16:00:13 +0000 Subject: [IronPython] IronPython Wiki Cookbook Message-ID: {ran_emo} One of the things I've been working on in my 'spare time': * `The IronPython Cookbook Wiki `_ This is a wiki with information about IronPython and code examples of how to achieve common tasks using IronPython and the .NET framework. There are links to my `IronPython Articles `_ (of course). New code examples include: * `Getting Started `_ * `Sending Udp Packets `_ * `Receiving Udp Packets `_ * `Download a Webpage `_ * `Databases with Odbc `_ * `Accessing the Registry `_ * `Speech Synthesis - Making IronPython Talk `_ There is a lot more to be done, but I hope this will be a useful resource for the IronPython community. Registration is required to create and edit pages, but if you have some useful examples of IronPython then *please* add them. If there is anything you *want to know how to do* with IronPython, then the `IronPython Mailing List `_ is a great place to ask. Useful code that turns up there will hopefully end up on the Wiki too. {sm;:-)} * `Ironpython.info - Contents `_ * `Ironpython.info - Useful Links `_ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at exchange.microsoft.com Wed May 30 18:31:06 2007 From: dinov at exchange.microsoft.com (Dino Viehland) Date: Wed, 30 May 2007 09:31:06 -0700 Subject: [IronPython] IronPython Wiki Cookbook In-Reply-To: References: Message-ID: <7AD436E4270DD54A94238001769C222791BCBF6627@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Very cool! From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of fuzzyman at voidspace.org.uk Sent: Wednesday, May 30, 2007 9:00 AM To: users at lists.ironpython.com Subject: [IronPython] IronPython Wiki Cookbook IronPython Wiki Cookbook [http://www.voidspace.org.uk/emoticons/nightmare.gif]One of the things I've been working on in my 'spare time': * The IronPython Cookbook Wiki This is a wiki with information about IronPython and code examples of how to achieve common tasks using IronPython and the .NET framework. There are links to my IronPython Articles (of course). New code examples include: * Getting Started * Sending Udp Packets * Receiving Udp Packets * Download a Webpage * Databases with Odbc * Accessing the Registry * Speech Synthesis - Making IronPython Talk There is a lot more to be done, but I hope this will be a useful resource for the IronPython community. Registration is required to create and edit pages, but if you have some useful examples of IronPython then please add them. If there is anything you want to know how to do with IronPython, then the IronPython Mailing List is a great place to ask. Useful code that turns up there will hopefully end up on the Wiki too. [http://www.voidspace.org.uk/smilies/smile.gif] * Ironpython.info - Contents * Ironpython.info - Useful Links Posted by Fuzzyman on 2007-05-30 16:34:59. Categories: Python, IronPython, Writing Visit the Voidspace Techie Blog to read this entry and more. -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Wed May 30 20:06:36 2007 From: timr at probo.com (Tim Roberts) Date: Wed, 30 May 2007 11:06:36 -0700 Subject: [IronPython] Console In-Reply-To: References: Message-ID: <465DBD2C.403@probo.com> On Tue, 29 May 2007 20:56:31 -0500, "Szurek, John" wrote: > > The console in Python is a real Windows window. When I run Python in > the Python console I get an output window that is a real Windows window. > All of that means that I can cut and paste freely into the code window > and I can cut and paste freely from the results window. The IronPython > "console" is not a console at all, it is the command line. Your first statement is simply not true. The native console in Python is a command line tool, just like in IronPython. Start a command shell and type "python" to see this. Now, it is true that the Windows Python distributions include a couple of applications that happen to put a pretty GUI wrapper around the command line interpreter (including IDLE and pythonwin), but those are just wrappers. They are not the "Python console". > It is clumsy > and clunky and virtually unusable unless you are pre-Windows and happen > to like command lines! The fact that you aren't familiar with it doesn't make it "clumsy and clunky". Python started out as a scripting language, so its roots lie deep in the command line mentality. Yes, I happen to like command lines. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From sanxiyn at gmail.com Thu May 31 03:09:50 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 31 May 2007 10:09:50 +0900 Subject: [IronPython] Patent concerns Message-ID: <5b0248170705301809l67915348hdc1346d61634f794@mail.gmail.com> Hi, Recently on jvm-languages list, which is an interest group surrounding language implementation for the JVM, Frank Wierzbicki from Jython project expressed the concern that Microsoft may hold a lot of patents related to IronPython, so he is reluctant to look at the source code even if it is open-sourced. http://groups.google.com/group/jvm-languages/msg/0d16a82b53233a72 Apparently, this seems to be a widespread concern. I think this is a pity, since in my opinion IronPython has a lot of good ideas that would benefit language implementations on JVM. So, please answer if possible. What patents Microsoft hold, related to IronPython? -- Seo Sanghyeon From sanxiyn at gmail.com Thu May 31 03:14:10 2007 From: sanxiyn at gmail.com (Sanghyeon Seo) Date: Thu, 31 May 2007 10:14:10 +0900 Subject: [IronPython] Console In-Reply-To: <742ac5140705300338p1ff241et62c70d017b1963ba@mail.gmail.com> References: <742ac5140705300338p1ff241et62c70d017b1963ba@mail.gmail.com> Message-ID: <5b0248170705301814w8b4563fn1b8e2c1662a7114b@mail.gmail.com> 2007/5/30, unrealportal : > I can't say this on behalf of Microsoft, but I am sure that the command line > window is just a quick way to have an interface to IronPython. I wouldn't be > concerned about this being the intended way to use IronPython on daily > basis. Is this the case? Actually, the command line interface is how *I* use CPython on daily basis, and I'm happy with IronPython one too. -- Seo Sanghyeon From hydonlee at gmail.com Thu May 31 03:26:59 2007 From: hydonlee at gmail.com (=?GB2312?B?tqvX0y9oeWRvbg==?=) Date: Thu, 31 May 2007 09:26:59 +0800 Subject: [IronPython] IronPython Wiki Cookbook In-Reply-To: <7AD436E4270DD54A94238001769C222791BCBF6627@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <7AD436E4270DD54A94238001769C222791BCBF6627@DF-GRTDANE-MSG.exchange.corp.microsoft.com> Message-ID: <3bc65bab0705301826g26f01f5aq7f146de5845364a5@mail.gmail.com> Thanks, It is very useful! 2007/5/31, Dino Viehland : > > Very cool! > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of * > fuzzyman at voidspace.org.uk > *Sent:* Wednesday, May 30, 2007 9:00 AM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] IronPython Wiki Cookbook > > > IronPython Wiki Cookbook > > [image: emoticon:nightmare]One of the things I've been working on in my > 'spare time': > > - The IronPython Cookbook Wiki > > This is a wiki with information about IronPython and code examples of how > to achieve common tasks using IronPython and the .NET framework. There are > links to my IronPython Articles(of course). > > New code examples include: > > - Getting Started > - Sending Udp Packets > - Receiving Udp Packets > - Download a Webpage > - Databases with Odbc > - Accessing the Registry > - Speech Synthesis - Making IronPython Talk > > There is a lot more to be done, but I hope this will be a useful resource > for the IronPython community. Registration is required to create and edit > pages, but if you have some useful examples of IronPython then *please*add them. > > If there is anything you *want to know how to do* with IronPython, then > the IronPython Mailing Listis a great place to ask. Useful code that turns up there will hopefully end > up on the Wiki too. [image: Smile] > > - Ironpython.info - Contents > - Ironpython.info - Useful Links > > Posted by *Fuzzyman* on 2007-05-30 16:34:59. > Categories: Python, > IronPython, > Writing > Visit the Voidspace Techie Blogto read this entry and more. > > _______________________________________________ > users mailing list > users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- ???????? TRY TO DO MY BEST -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarmer at thuban.org Thu May 31 08:18:48 2007 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 30 May 2007 23:18:48 -0700 Subject: [IronPython] Patent concerns In-Reply-To: <5b0248170705301809l67915348hdc1346d61634f794@mail.gmail.com> References: <5b0248170705301809l67915348hdc1346d61634f794@mail.gmail.com> Message-ID: The answer to that probably requires a patent lawyer, and since we've each been trained in the mantra, "I am not a lawyer", it follows that "We are not patent lawyers." This is particularly true when talking amongst developers, since what we might consider patentable and not varies dramatically from what Legal would advise. So, short of someone from MS Legal chiming in, I would (personally) advise interested parties to consult their own (professional) legal counsel. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sanghyeon Seo Sent: Wednesday, May 30, 2007 6:10 PM To: Discussion of IronPython Subject: [IronPython] Patent concerns Hi, Recently on jvm-languages list, which is an interest group surrounding language implementation for the JVM, Frank Wierzbicki from Jython project expressed the concern that Microsoft may hold a lot of patents related to IronPython, so he is reluctant to look at the source code even if it is open-sourced. http://groups.google.com/group/jvm-languages/msg/0d16a82b53233a72 Apparently, this seems to be a widespread concern. I think this is a pity, since in my opinion IronPython has a lot of good ideas that would benefit language implementations on JVM. So, please answer if possible. What patents Microsoft hold, related to IronPython? -- Seo Sanghyeon _______________________________________________ users mailing list users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com