From oneeyedelf1 at gmail.com Wed Oct 1 03:13:33 2008 From: oneeyedelf1 at gmail.com (Knic Knic) Date: Tue, 30 Sep 2008 18:13:33 -0700 Subject: [IronPython] How do I impersonate? Message-ID: <48e2ceb1.1b068e0a.4a9d.ffff87db@mx.google.com> I want to generate an account token, but I cannot seem to find anything like LogonUser to call. Thanks, Knic -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jimmy.Schementi at microsoft.com Wed Oct 1 08:27:02 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Tue, 30 Sep 2008 23:27:02 -0700 Subject: [IronPython] Anyone have IronPython running on Silverlight RC0 yet? In-Reply-To: <4817b6fc0809301355s24e1441bufd6eb7f90d739bc6@mail.gmail.com> References: <4817b6fc0809291920t6b5794afob9b5187cd2627f21@mail.gmail.com> <5283CA0A4168DF4FBBD71AE9ECA5A328489FEB92DA@NA-EXMSG-C116.redmond.corp.microsoft.com> <4817b6fc0809301355s24e1441bufd6eb7f90d739bc6@mail.gmail.com> Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A328489FEB9A17@NA-EXMSG-C116.redmond.corp.microsoft.com> http://blog.jimmy.schementi.com/2008/09/compiling-dlr-ironruby-and-ironpython.html > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Dan Eloff > Sent: Tuesday, September 30, 2008 1:55 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Anyone have IronPython running on Silverlight > RC0 yet? > > On Tue, Sep 30, 2008 at 11:12 AM, Jimmy Schementi > wrote: > > The "obsolete version of Silverlight" error is because in the XAP > file, the AppManifest.xaml has the RuntimeVersion for beta2, not rc0. > If you're using Chiron, open Chiron.exe.config and in the > section edit the RuntimeVersion to be > "2.0.30923.0". > > > > Thanks!! That was exactly the problem. You should post that on your > blog, I'm probably not the only one wondering why things weren't > working. > > -Dan > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From Jimmy.Schementi at microsoft.com Wed Oct 1 09:15:27 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Wed, 1 Oct 2008 00:15:27 -0700 Subject: [IronPython] Dynamic Languages in Silverlight 2 RC0 Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A328489FEB9A1B@NA-EXMSG-C116.redmond.corp.microsoft.com> All, Visit http://codeplex.com/sdlsdk to download IronPython and IronRuby binaries for Silverlight 2 RC0! Here's the direct release page (http://www.codeplex.com/sdlsdk/Release/ProjectReleases.aspx?ReleaseId=17839) and you can read more about it on my blog (http://blog.jimmy.schementi.com/2008/10/dynamic-languages-in-silverlight-2-rc0.html). As always, please report any issues to the Issues tab (http://www.codeplex.com/sdlsdk/WorkItem/List.aspx) and feel free to ask questions here or on the Discussions tab(http://www.codeplex.com/sdlsdk/Thread/List.aspx). Enjoy! ~Jimmy From kfarmer at thuban.org Wed Oct 1 09:21:49 2008 From: kfarmer at thuban.org (Keith J. Farmer) Date: Wed, 1 Oct 2008 00:21:49 -0700 Subject: [IronPython] Dynamic Languages in Silverlight 2 RC0 In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A328489FEB9A1B@NA-EXMSG-C116.redmond.corp.microsoft.com> References: <5283CA0A4168DF4FBBD71AE9ECA5A328489FEB9A1B@NA-EXMSG-C116.redmond.corp.microsoft.com> Message-ID: Google Error Not Found The requested URL /2008/10/dynamic-languages-in-silverlight-2-rc0.html was not found on this server. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jimmy Schementi Sent: Wednesday, October 01, 2008 12:15 AM To: ironruby-core at rubyforge.org; Discussion of IronPython Subject: [IronPython] Dynamic Languages in Silverlight 2 RC0 All, Visit http://codeplex.com/sdlsdk to download IronPython and IronRuby binaries for Silverlight 2 RC0! Here's the direct release page (http://www.codeplex.com/sdlsdk/Release/ProjectReleases.aspx?ReleaseId=17839) and you can read more about it on my blog (http://blog.jimmy.schementi.com/2008/10/dynamic-languages-in-silverlight-2-rc0.html). As always, please report any issues to the Issues tab (http://www.codeplex.com/sdlsdk/WorkItem/List.aspx) and feel free to ask questions here or on the Discussions tab(http://www.codeplex.com/sdlsdk/Thread/List.aspx). Enjoy! ~Jimmy _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From ivan at flanders.co.nz Wed Oct 1 09:27:50 2008 From: ivan at flanders.co.nz (Ivan Porto Carrero) Date: Wed, 1 Oct 2008 09:27:50 +0200 Subject: [IronPython] Dynamic Languages in Silverlight 2 RC0 In-Reply-To: References: <5283CA0A4168DF4FBBD71AE9ECA5A328489FEB9A1B@NA-EXMSG-C116.redmond.corp.microsoft.com> Message-ID: Works for me On Wed, Oct 1, 2008 at 9:21 AM, Keith J. Farmer wrote: > Google Error > > Not Found > The requested URL /2008/10/dynamic-languages-in-silverlight-2-rc0.html was > not found on this server. > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Jimmy Schementi > Sent: Wednesday, October 01, 2008 12:15 AM > To: ironruby-core at rubyforge.org; Discussion of IronPython > Subject: [IronPython] Dynamic Languages in Silverlight 2 RC0 > > All, > > Visit http://codeplex.com/sdlsdk to download IronPython and IronRuby > binaries for Silverlight 2 RC0! Here's the direct release page ( > http://www.codeplex.com/sdlsdk/Release/ProjectReleases.aspx?ReleaseId=17839) > and you can read more about it on my blog ( > http://blog.jimmy.schementi.com/2008/10/dynamic-languages-in-silverlight-2-rc0.html > ). > > As always, please report any issues to the Issues tab ( > http://www.codeplex.com/sdlsdk/WorkItem/List.aspx) and feel free to ask > questions here or on the Discussions tab( > http://www.codeplex.com/sdlsdk/Thread/List.aspx). > > Enjoy! > ~Jimmy > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfugate at microsoft.com Wed Oct 1 17:51:36 2008 From: dfugate at microsoft.com (Dave Fugate) Date: Wed, 1 Oct 2008 08:51:36 -0700 Subject: [IronPython] What happened to source drops? In-Reply-To: <48E27B15.3010701@voidspace.org.uk> References: <4817b6fc0809291323k52a7dc6cj9976fcb5ac6ce290@mail.gmail.com> <350E7D38B6D819428718949920EC235547877B9A24@NA-EXMSG-C102.redmond.corp.microsoft.com> <48E14564.1050403@voidspace.org.uk> <350E7D38B6D819428718949920EC235547877B9A48@NA-EXMSG-C102.redmond.corp.microsoft.com> <48E148C3.9030207@voidspace.org.uk> <350E7D38B6D819428718949920EC235547877B9A65@NA-EXMSG-C102.redmond.corp.microsoft.com> <48E27B15.3010701@voidspace.org.uk> Message-ID: My best guess is the fixes will be in the 2.0 branch sometime next week. Offhand, I don't believe the package/module compiling fixes are in yet (e.g., the cyclic dependencies bug is fixed in 2.1, but not 2.0). Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Tuesday, September 30, 2008 12:17 PM To: Discussion of IronPython Subject: Re: [IronPython] What happened to source drops? Dave Fugate wrote: > Actually there was a little confusion internally and the 40877 changeset uploaded to CodePlex yesterday corresponds to our new IronPython 2.1 branch. In turn, the 2.1 branch was the reason there's been no source pushes for the past two weeks - some scripts and TFS enlistments needed updating to re-enable IP 2.0 source updates. > > The latest update, changeset 40917, comes from our IronPython 2.0 branch and does not yet include most of the fixes in changeset 40877. If you want these now (and possibly some changes that won't be making it into IP 2.0), use http://www.codeplex.com/IronPython/SourceControl/DownloadSourceCode.aspx?changeSetId=40877. Otherwise, we hope to have the fixes included in TFS within a week. Sorry for any confusion about this. > > No problem. Any ETA on getting the features that will make it in to 2.0 available in a code drop? Are the 'compiling packages' fixes in the current 2.0 branch code drop? Michael > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Srivatsn Narayanan > Sent: Monday, September 29, 2008 3:12 PM > To: Discussion of IronPython > Subject: Re: [IronPython] What happened to source drops? > > I've pushed out a source drop with the latest sources - http://www.codeplex.com/IronPython/SourceControl/ListDownloadableCommits.aspx > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Monday, September 29, 2008 2:40 PM > To: Discussion of IronPython > Subject: Re: [IronPython] What happened to source drops? > > I would actually suggest compiling the standard modules as well as your code and then ngen them both on install. You can compile the std modules into their own .dll so the user can always replace them w/ their own version (or they can simply delete the DLL and then pick up the .py files). > > The reason I suggest this is with the bits on my machine I'm seeing massive import speed ups w/ pre-compilation + ngen (e.g. 3x or so). > > And decimal does import a lot more - but the real working set hit came from publishing all the SymbolIDs for every precompiled module - once for each module - on startup! A small oversight :)... But there were a few other areas that could use some improvement as well. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, September 29, 2008 2:30 PM > To: Discussion of IronPython > Subject: Re: [IronPython] What happened to source drops? > > Dino Viehland wrote: > >> They're checked in so they'll be in the next source push. There are some perf problems that I have fixes for though that aren't checked in (e.g. import decimal in pre-compiled currently allocates ~550MB of memory) - but you should be able to do functional testing :). I'll should have the pre-comp perf fixes in this week. >> >> > > Cool - thanks. 550mb for one module - wow. Good job we aren't intending > to precompile the Python standard library modules we're using. Having > said that we have quite a chunk of Python source we would like to > compile - I wonder if a 4gb address space will be enough. I think we > will be reluctant to move to 64bit oses only... ;-) > > Michael > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Monday, September 29, 2008 2:15 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] What happened to source drops? >> >> Dino Viehland wrote: >> >> >>> It looks like the script which automatically publishes the code has stopped publishing the updates. Dave's OOF today and I can't find the original instructions but Sri's looking into it. >>> >>> >>> >> Cool. If you get the compiling packages fixes into a code drop please >> let me know so that we can start testing them early. >> >> Thanks >> >> Michael Foord >> >> >> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff >>> Sent: Monday, September 29, 2008 1:23 PM >>> To: Discussion of IronPython >>> Subject: [IronPython] What happened to source drops? >>> >>> I'm noticing that the last source drop was the beta 5 release two weeks ago. >>> >>> I don't mean to pressure you guys, but I am looking forward to the >>> next source release, which seems to have the delegate regressions >>> fixed. Any (vague) idea of when regular source drops will be resumed? >>> >>> By the way, I built IronPython b5 for Silverlight RC0, and I had to >>> modify Microsoft.Scripting.Silverlight.ErrorFormatter: >>> >>> - HtmlPage.Document.GetElementsByTagName("body")[0].AppendChild(target); >>> + ((HtmlElement)HtmlPage.Document.GetElementsByTagName("body")[0]).AppendChild(target); >>> >>> I'm not fully sure how this code compiled in the first place, as >>> ScriptObject never had an AppendChild method. Probably this code has >>> already been fixed, but it's worth checking anyway. >>> >>> -Dan >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >> -- >> http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/ >> http://www.trypython.org/ >> http://www.ironpython.info/ >> http://www.theotherdelia.co.uk/ >> http://www.resolverhacks.net/ >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.theotherdelia.co.uk/ > http://www.resolverhacks.net/ > > _______________________________________________ > 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 > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From curt at hagenlocher.org Wed Oct 1 18:10:17 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 1 Oct 2008 09:10:17 -0700 Subject: [IronPython] InvalidProgramException exception with NUnit In-Reply-To: <8140eff40809300719o2354650ena0c9a9badc9c225f@mail.gmail.com> References: <8140eff40809261200i3740f37dj2bd8dd7146cdb5a6@mail.gmail.com> <350E7D38B6D819428718949920EC235547877B979A@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40809291041l7a55fff4pb6e8503e6f61f3ac@mail.gmail.com> <8140eff40809300719o2354650ena0c9a9badc9c225f@mail.gmail.com> Message-ID: On Tue, Sep 30, 2008 at 7:19 AM, Fernando Correia wrote: > > The sample test I provided runs without problem when it is executed > directly by NUnit, but fails if NUnit is being called by some other > layer, like the TestDriven.NET plugin for Visual Studio or the NCover > code coverage tool. I don't have either of these tools. Do you know of a freely-available substitute that could work instead? -- Curt Hagenlocher curt at hagenlocher.org From fernandoacorreia at gmail.com Wed Oct 1 18:41:30 2008 From: fernandoacorreia at gmail.com (Fernando Correia) Date: Wed, 1 Oct 2008 13:41:30 -0300 Subject: [IronPython] InvalidProgramException exception with NUnit In-Reply-To: References: <8140eff40809261200i3740f37dj2bd8dd7146cdb5a6@mail.gmail.com> <350E7D38B6D819428718949920EC235547877B979A@NA-EXMSG-C102.redmond.corp.microsoft.com> <8140eff40809291041l7a55fff4pb6e8503e6f61f3ac@mail.gmail.com> <8140eff40809300719o2354650ena0c9a9badc9c225f@mail.gmail.com> Message-ID: <8140eff40810010941j4551a5abvb714635081e7ad21@mail.gmail.com> 2008/10/1 Curt Hagenlocher : > I don't have either of these tools. Do you know of a freely-available > substitute that could work instead? Curt, no, but both TestDriven.NET and NCover have editions that can be freely downloaded. NCover has a 30-day trial version as well as free-to-use discontinued versions: http://www.ncover.com/download/discontinued TestDriven.NET also can be freely downloaded for trial and for open-source development: http://www.testdriven.net/download.aspx I realize that this issue won't affect too many people (not everyone uses NDepend and NUnit, after all). But if you plan to look into this problem I think I can provide you with a test scenario in the form of a batch file that executes NDepend, that executes NUnit, that executes a test fixture that uses IronPython... From fuzzyman at voidspace.org.uk Wed Oct 1 22:22:02 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 01 Oct 2008 21:22:02 +0100 Subject: [IronPython] What happened to source drops? In-Reply-To: References: <4817b6fc0809291323k52a7dc6cj9976fcb5ac6ce290@mail.gmail.com> <350E7D38B6D819428718949920EC235547877B9A24@NA-EXMSG-C102.redmond.corp.microsoft.com> <48E14564.1050403@voidspace.org.uk> <350E7D38B6D819428718949920EC235547877B9A48@NA-EXMSG-C102.redmond.corp.microsoft.com> <48E148C3.9030207@voidspace.org.uk> <350E7D38B6D819428718949920EC235547877B9A65@NA-EXMSG-C102.redmond.corp.microsoft.com> <48E27B15.3010701@voidspace.org.uk> Message-ID: <48E3DBEA.7090105@voidspace.org.uk> Dave Fugate wrote: > My best guess is the fixes will be in the 2.0 branch sometime next week. Offhand, I don't believe the package/module compiling fixes are in yet (e.g., the cyclic dependencies bug is fixed in 2.1, but not 2.0). > > Ok - thanks. Michael > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Tuesday, September 30, 2008 12:17 PM > To: Discussion of IronPython > Subject: Re: [IronPython] What happened to source drops? > > Dave Fugate wrote: > >> Actually there was a little confusion internally and the 40877 changeset uploaded to CodePlex yesterday corresponds to our new IronPython 2.1 branch. In turn, the 2.1 branch was the reason there's been no source pushes for the past two weeks - some scripts and TFS enlistments needed updating to re-enable IP 2.0 source updates. >> >> The latest update, changeset 40917, comes from our IronPython 2.0 branch and does not yet include most of the fixes in changeset 40877. If you want these now (and possibly some changes that won't be making it into IP 2.0), use http://www.codeplex.com/IronPython/SourceControl/DownloadSourceCode.aspx?changeSetId=40877. Otherwise, we hope to have the fixes included in TFS within a week. Sorry for any confusion about this. >> >> >> > > No problem. Any ETA on getting the features that will make it in to 2.0 > available in a code drop? Are the 'compiling packages' fixes in the > current 2.0 branch code drop? > > Michael > > >> Dave >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Srivatsn Narayanan >> Sent: Monday, September 29, 2008 3:12 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] What happened to source drops? >> >> I've pushed out a source drop with the latest sources - http://www.codeplex.com/IronPython/SourceControl/ListDownloadableCommits.aspx >> >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland >> Sent: Monday, September 29, 2008 2:40 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] What happened to source drops? >> >> I would actually suggest compiling the standard modules as well as your code and then ngen them both on install. You can compile the std modules into their own .dll so the user can always replace them w/ their own version (or they can simply delete the DLL and then pick up the .py files). >> >> The reason I suggest this is with the bits on my machine I'm seeing massive import speed ups w/ pre-compilation + ngen (e.g. 3x or so). >> >> And decimal does import a lot more - but the real working set hit came from publishing all the SymbolIDs for every precompiled module - once for each module - on startup! A small oversight :)... But there were a few other areas that could use some improvement as well. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Monday, September 29, 2008 2:30 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] What happened to source drops? >> >> Dino Viehland wrote: >> >> >>> They're checked in so they'll be in the next source push. There are some perf problems that I have fixes for though that aren't checked in (e.g. import decimal in pre-compiled currently allocates ~550MB of memory) - but you should be able to do functional testing :). I'll should have the pre-comp perf fixes in this week. >>> >>> >>> >> Cool - thanks. 550mb for one module - wow. Good job we aren't intending >> to precompile the Python standard library modules we're using. Having >> said that we have quite a chunk of Python source we would like to >> compile - I wonder if a 4gb address space will be enough. I think we >> will be reluctant to move to 64bit oses only... ;-) >> >> Michael >> >> >> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >>> Sent: Monday, September 29, 2008 2:15 PM >>> To: Discussion of IronPython >>> Subject: Re: [IronPython] What happened to source drops? >>> >>> Dino Viehland wrote: >>> >>> >>> >>>> It looks like the script which automatically publishes the code has stopped publishing the updates. Dave's OOF today and I can't find the original instructions but Sri's looking into it. >>>> >>>> >>>> >>>> >>> Cool. If you get the compiling packages fixes into a code drop please >>> let me know so that we can start testing them early. >>> >>> Thanks >>> >>> Michael Foord >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff >>>> Sent: Monday, September 29, 2008 1:23 PM >>>> To: Discussion of IronPython >>>> Subject: [IronPython] What happened to source drops? >>>> >>>> I'm noticing that the last source drop was the beta 5 release two weeks ago. >>>> >>>> I don't mean to pressure you guys, but I am looking forward to the >>>> next source release, which seems to have the delegate regressions >>>> fixed. Any (vague) idea of when regular source drops will be resumed? >>>> >>>> By the way, I built IronPython b5 for Silverlight RC0, and I had to >>>> modify Microsoft.Scripting.Silverlight.ErrorFormatter: >>>> >>>> - HtmlPage.Document.GetElementsByTagName("body")[0].AppendChild(target); >>>> + ((HtmlElement)HtmlPage.Document.GetElementsByTagName("body")[0]).AppendChild(target); >>>> >>>> I'm not fully sure how this code compiled in the first place, as >>>> ScriptObject never had an AppendChild method. Probably this code has >>>> already been fixed, but it's worth checking anyway. >>>> >>>> -Dan >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.ironpython.com >>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.ironpython.com >>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>>> >>>> >>>> >>>> >>> -- >>> http://www.ironpythoninaction.com/ >>> http://www.voidspace.org.uk/ >>> http://www.trypython.org/ >>> http://www.ironpython.info/ >>> http://www.theotherdelia.co.uk/ >>> http://www.resolverhacks.net/ >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >> -- >> http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/ >> http://www.trypython.org/ >> http://www.ironpython.info/ >> http://www.theotherdelia.co.uk/ >> http://www.resolverhacks.net/ >> >> _______________________________________________ >> 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 >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.theotherdelia.co.uk/ > http://www.resolverhacks.net/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From desleo at gmail.com Thu Oct 2 22:09:49 2008 From: desleo at gmail.com (Leo Carbajal) Date: Thu, 2 Oct 2008 15:09:49 -0500 Subject: [IronPython] Syntax Checking Message-ID: Is there any way to check the syntax of a script without actually running the script? Akin to the way VStudio does the 'code smells' nowadays. Of course, by 'any way' I'm probably asking if there's an 'easy way', but I'll take the hard way, too, if it's something I can figure out and re-use. --- V -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Oct 2 22:28:35 2008 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 2 Oct 2008 13:28:35 -0700 Subject: [IronPython] Syntax Checking In-Reply-To: References: Message-ID: <350E7D38B6D819428718949920EC2355478913AA1C@NA-EXMSG-C102.redmond.corp.microsoft.com> In 2.0 you can call GetCodeProperties on a ScriptSource and it'll give you an indication of how the code is. You can also call ScriptSource.Compile w/ an ErrorListener which can get more detailed information about the failures. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Leo Carbajal Sent: Thursday, October 02, 2008 1:10 PM To: Users at lists.ironpython.com Subject: [IronPython] Syntax Checking Is there any way to check the syntax of a script without actually running the script? Akin to the way VStudio does the 'code smells' nowadays. Of course, by 'any way' I'm probably asking if there's an 'easy way', but I'll take the hard way, too, if it's something I can figure out and re-use. --- V -------------- next part -------------- An HTML attachment was scrubbed... URL: From desleo at gmail.com Fri Oct 3 09:12:24 2008 From: desleo at gmail.com (Leo Carbajal) Date: Fri, 3 Oct 2008 02:12:24 -0500 Subject: [IronPython] Execute and IronPython Message-ID: Howdy again, According to the hosting spec each language defines how, and what, to return at the end of a script when using Execute, is there a way to do this on IronPython? I've tried a couple of things, such as from Dirt import * def echo(x): return x kitty = Cat() kitty.Name = "Tito" kitty.Meow() kitty As an alternative, I'm using the following with the above Python code. public static T GetObject(string fileName, string objectName) { try { string path = String.Format("{0}{1}{2}.py", BaseDir, @"\HostScripts\", fileName); ScriptSource source = privateEngine.CreateScriptSourceFromFile(path); source.Execute(); return privateEngine.GetVariable(privateEngine.GetScope(path), objectName); } //catches ommitted for space } Cat tito = DynamicServices.GetObject("MUDConfig", "kitty"); Console.WriteLine(tito.Name); I'd like to load my configuration files\classes and handle 'serialization' via Python scripts, for various reasons, and using Execute would prevent me from having to pick and choose specific names. (I.E. Kitty - since that would be hardcoded in the C# source) --- V -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Fri Oct 3 17:34:29 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 3 Oct 2008 08:34:29 -0700 Subject: [IronPython] How do I impersonate? In-Reply-To: <48e2ceb1.1b068e0a.4a9d.ffff87db@mx.google.com> References: <48e2ceb1.1b068e0a.4a9d.ffff87db@mx.google.com> Message-ID: This question is a little open-ended and probably not specific to IronPython. You might have some more luck in a different context. >From what I recall, there's no way to do something like LogonUser from .NET without making a P/Invoke call to the underlying Windows API. P/Invoke isn't currently supported directly from IronPython; you'd either have to do the hard part by using System.Reflection.Emit to generate the code yourself or you'd have to write a small C# assembly that contains the P/Invoke definitions you need and then use those definitions from IronPython. On Tue, Sep 30, 2008 at 6:13 PM, Knic Knic wrote: > I want to generate an account token, but I cannot seem to find anything > like LogonUser to call. > > Thanks, > Knic > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Fri Oct 3 17:26:35 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 3 Oct 2008 08:26:35 -0700 Subject: [IronPython] Execute and IronPython In-Reply-To: References: Message-ID: I agree with you that hardcoding a specific variable name in your hosting code feels like a poor design decision. What I'd do instead is to import a "set_return_value" function from the hosting app into the Python script, then the last line of the script would be something like "host.set_return_value(kitty)". On some level, the two approaches are not much different from each other -- but a hardcoded function name is an "API" while a hardcoded variable name is "magic". :) The notion of a return value from a script doesn't exist in the Python language. On Fri, Oct 3, 2008 at 12:12 AM, Leo Carbajal wrote: > Howdy again, > > According to the hosting spec each language defines how, and what, to > return at the end of a script when using Execute, is there a way to do > this on IronPython? I've tried a couple of things, such as > > from Dirt import * > > def echo(x): > return x > > kitty = Cat() > kitty.Name = "Tito" > kitty.Meow() > kitty > > As an alternative, I'm using the following with the above Python code. > > public static T GetObject(string fileName, string objectName) > { > try > { > string path = String.Format("{0}{1}{2}.py", BaseDir, > @"\HostScripts\", fileName); > ScriptSource source = > privateEngine.CreateScriptSourceFromFile(path); > source.Execute(); > return > privateEngine.GetVariable(privateEngine.GetScope(path), objectName); > } > //catches ommitted for space > } > > Cat tito = DynamicServices.GetObject("MUDConfig", "kitty"); > Console.WriteLine(tito.Name); > > I'd like to load my configuration files\classes and handle 'serialization' > via Python scripts, for various reasons, and using Execute would prevent me > from having to pick and choose specific names. (I.E. Kitty - since that > would be hardcoded in the C# source) > > --- > V > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sat Oct 4 12:22:24 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 04 Oct 2008 11:22:24 +0100 Subject: [IronPython] [Fwd: Re: [pyconuk] Parallel Processing and Python] Message-ID: <48E743E0.6020709@voidspace.org.uk> Out of a discussion on multithreading on the PyCon UK mailing list - it turns out that Kamaelia (a concurrency library) 'mainly' works on IronPython 2 now - which is great news. I believe Michael Sparks will be filing at least one bug report - but some issues that used to prevent it working have been fixed. -------- Original Message -------- Subject: Re: [pyconuk] Parallel Processing and Python Date: Fri, 3 Oct 2008 16:59:38 +0100 From: Michael Sparks Organization: Just little old me To: Michael Foord CC: pyconuk at python.org, kamaelia at googlegroups.com, Discussion of IronPython References: <48D00408.50705 at simplistix.co.uk> <200810031620.42992.sparks.m at gmail.com> <48E639E1.4040602 at voidspace.org.uk> > Amongst everything you posted below I could only *see* problems with > using setuptools and distutils Correct. > - neither of which I particularly expect to work unmodified in IronPython > for the *forseeable* future. Ahhh, I didn't realise that. That means fundamentally you can view it as driver error in that case. If there's a preferred packaging scheme for IronPython, I'll see if we can support that as well. I wasn't aware of the various points, that explains a lot. Well in which case, more works than can be expected :) > As far as I could *see* actually *using* Kamaelia worked fine (other > than the echoer server client disconnection issue you mentioned) - am I > reading that right? If so it is a massive step forward and fantastic news. Yes, it is a massive step forward and it is *fantastic* news. Whilst the examples I posted are relatively simple, I know which areas that are getting exercised by this - like putting select in a different thread, communications using Queue.Queue, things like multiple yield statements in generators etc. This does mean that all the examples I've posted will fairly trivially be multicore :-) Since posting the last message, I've also tested TCPClient, which used to exercise a particular bug in IronPython because of this structure: [snip] yield 2 raise Finality except Exception, x: result = sock.shutdown(2) ; yield 3 raise x # XXXX If X is not finality.. [snip] except Exception, x: sock.close() ; yield 4,x # XXXX If X is not finality.. [snip] raise x except Finality: yield 5 except socket.error, e: # We now do the flipside of setupCSA, whether we had an error or not # A safe error relates to a disconnected server, and unsafe error is [snip] In case that looks odd, it's due to the issue that try:...finally:... is not legal inside a generator in python pre-2.5. This particular structure used to cause problems for IronPython, and I'm glad to see that's been fixed: C:\Program Files\IronPython 2.0 Beta 5>ipy.exe IronPython 2.0 Beta (2.0.0.5000) on .NET 2.0.50727.1433 Type "help", "copyright", "credits" or "license" for more information. >>> import Axon >>> import Kamaelia >>> from Kamaelia.Chassis.Pipeline import Pipeline >>> from Kamaelia.Util.Console import * >>> from Kamaelia.Internet.TCPClient import TCPClient >>> Pipeline( ... ConsoleReader(), ... TCPClient("132.185.142.2", 80), ... ConsoleEchoer(), ... ).run() Then the output of that run: (GET .. etc is typed by me) >>> GET / HTTP/1.0 >>> >>> HTTP/1.1 200 OK Date: Fri, 03 Oct 2008 14:19:40 GMT Server: Apache/2.0.49 (Linux/SuSE) Last-Modified: Wed, 21 May 2008 21:14:05 GMT ETag: "32663b2-6f-139fa140" Accept-Ranges: bytes Content-Length: 111 Connection: close Content-Type: text/html; charset=ISO-8859-1

Today's fish is trout ala creme, please enjoy your meal. Traceback (most recent call last): File "", line unknown, in File "Snippets.scripting", line unknown, in run File "Snippets.scripting", line unknown, in runThreads File "Microsoft.Scripting.Core", line unknown, in MoveNext File "Snippets.scripting", line unknown, in main ValueError: list.index(item): item not in list > Could you post details of the disconnection issue? I had wanted to check whether it was a Kamaelia bug. However, it looks like it is an IronPython issue. However, running the above example shows up the same bug in IronPython - where as it functions correctly on CPython. :-) That said, I really think that is a massive jump forward for Kamaelia on IronPython and think it's fantastic news :) Regards, Michael. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From wangym at gmail.com Sun Oct 5 03:34:12 2008 From: wangym at gmail.com (Yongming) Date: Sat, 4 Oct 2008 18:34:12 -0700 (PDT) Subject: [IronPython] Visit Scope property of class CommandLine Message-ID: <6cb96d4a-440d-464e-908b-7629e71f407f@p31g2000prf.googlegroups.com> Hi, When tried to embed IronPython console into my application, I need expose some object to the console's CommandLine's scope. But the Scope property of class CommandLine is protected. So is there another way to do this? Thanks, Yongming From dinov at microsoft.com Sun Oct 5 03:42:16 2008 From: dinov at microsoft.com (Dino Viehland) Date: Sat, 4 Oct 2008 18:42:16 -0700 Subject: [IronPython] Visit Scope property of class CommandLine In-Reply-To: <6cb96d4a-440d-464e-908b-7629e71f407f@p31g2000prf.googlegroups.com> References: <6cb96d4a-440d-464e-908b-7629e71f407f@p31g2000prf.googlegroups.com> Message-ID: <350E7D38B6D819428718949920EC2355478913B209@NA-EXMSG-C102.redmond.corp.microsoft.com> You could just subclass it and expose it publicly under another name. Other than that you'd need to just use the general hosting APIs to do what the command line is doing. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Yongming Sent: Saturday, October 04, 2008 6:34 PM To: users at lists.ironpython.com Subject: [IronPython] Visit Scope property of class CommandLine Hi, When tried to embed IronPython console into my application, I need expose some object to the console's CommandLine's scope. But the Scope property of class CommandLine is protected. So is there another way to do this? Thanks, Yongming _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Sun Oct 5 09:21:09 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Sun, 5 Oct 2008 16:21:09 +0900 Subject: [IronPython] Yield Prolog Benchmarks Message-ID: <5b0248170810050021v7f4811cs63631baa1dde1fde@mail.gmail.com> Yield Prolog is an embeddable Prolog implementation that compiles to Python, C#, or JavaScript using "yield" statements in those languages. http://yieldprolog.sourceforge.net/ It comes with a nice benchmark calculating 2680 solutions of 11-queens problem in Prolog. So I tried it out of curiosity. http://yieldprolog.sourceforge.net/benchmarks.html How to run: svn co https://yieldprolog.svn.sourceforge.net/svnroot/yieldprolog/YieldProlog yieldprolog cd yieldprolog/source/python # Edit Compiler.py to comment out "from compiler import *". It is not needed. cd examples/Benchmarks python queens.py Intel Core 2 T7200 2.00GHz 2.00GB RAM Microsoft Windows XP Home Edition SP2 Python 2.5.1 36.2195480152 36.3135356589 36.0008464763 IronPython 2.0 Beta 5 on .NET Framework 3.5 SP1 52.5789892291 53.0868051666 53.0352047537 In this particular benchmark, IronPython 2 comes about 30% slower than Python 2.5. Mono is much, much slower than .NET for this particular benchmark, by the way. I am investigating. -- Seo Sanghyeon From g.mulot at free.fr Sun Oct 5 19:47:20 2008 From: g.mulot at free.fr (Gerard Mulot) Date: Sun, 5 Oct 2008 19:47:20 +0200 Subject: [IronPython] LeeBeLLuL and IronPython, an another way to use Google App Engine Message-ID: <001201c92712$6a8eae40$3fac0ac0$@mulot@free.fr> I developed an application with LeeBeLLuL that communicates with Google App Engine in SOAP. I mainly use the DataStore, process are done on the PC. I think GAE is an effective platform with good response time, whose implementation is easy with SOAP. http://www.leebellul.com/Site/APPLICATIONS/Ressources_Humaines_V1.html Regards LeeBeLLuL -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sun Oct 5 20:03:29 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 05 Oct 2008 19:03:29 +0100 Subject: [IronPython] LeeBeLLuL and IronPython, an another way to use Google App Engine In-Reply-To: <001201c92712$6a8eae40$3fac0ac0$@mulot@free.fr> References: <001201c92712$6a8eae40$3fac0ac0$@mulot@free.fr> Message-ID: <48E90171.20008@voidspace.org.uk> Gerard Mulot wrote: > > I developed an application with LeeBeLLuL that communicates with > Google App Engine in SOAP. I mainly use the DataStore, process are > done on the PC. > I think GAE is an effective platform with good response time, whose > implementation is easy with SOAP. > > http://www.leebellul.com/Site/APPLICATIONS/Ressources_Humaines_V1.html > > > Any example IronPython code to go with that? Michael > Regards > LeeBeLLuL > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ From sefirah6990 at katamail.com Sun Oct 5 20:25:08 2008 From: sefirah6990 at katamail.com (sefirah6990 at katamail.com) Date: Sun, 5 Oct 2008 20:25:08 +0200 Subject: [IronPython] FunctionEnvironment16Dictionary problems with IronPythonStudio Message-ID: <17483.1223231108@katamail.com> Hi, I'm new to IronPythonStudio. I choose this environment in order to create .NET assemblies (dll) from IronPython code and use them into a .NET project (like C#, J# or so). I've noticed that some conversions between IP code and compiled dll were made by IronPythonStudio compiler, for example the names of every user-defined method change from "methodName" to "MethodName$f19" (a suffix like "$f" is appended)..no problems about that. The convertion that is causing me a lot of troubles is about method parameters. Example: if my init method was: __init__(self, n, s, m) after compilation becomes: __init__$f0(FunctionEnvironment16Dictionary _env, Object self, Object n, Object s, Object m) Well, where should i get the correct instance of FunctionEnvironment16Dictionary? If i create a new object of this type and try to invoke init in this way: (now we are into a C# project) Student stu2 = new Student(); stu2.__init__$f0(new FunctionEnvironment16Dictionary(), stu2, "hello", "world", "!!!"); the system always throw a NullReferenceException in the second line.. Here is the stack trace: at IronPython.Runtime.Calls.FunctionEnvironmentDictionary.get_Module() at IronPython.Runtime.Operations.Ops.UpdateTraceBack(ICallerContext context, String filename, Int32 line, String funcName, Boolean& notHandled) at Student.__init__$f0(FunctionEnvironment16Dictionary $env, Object self, Object n, Object s, Object m) at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args) at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ThreadHelper.ThreadStart_Context(Object state) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() Seems that a Module is required but i don't understand what should i do... Someone could explain where is my mistake? Thanks a lot!! Marco ---- Nuova grafica e nuove funzionalit?! Crea subito Gratis la tua nuova Casella di Posta Katamail From curt at hagenlocher.org Sun Oct 5 21:15:57 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Sun, 5 Oct 2008 12:15:57 -0700 Subject: [IronPython] FunctionEnvironment16Dictionary problems with IronPythonStudio In-Reply-To: <17483.1223231108@katamail.com> References: <17483.1223231108@katamail.com> Message-ID: Unfortunately, it's currently much easier to use C# (or "native CLS") code from within IronPython than it is to use IronPython from within C#. To do this properly, you'll generally need to use the hosting interfaces -- and they've changed pretty dramatically between 1.1 and 2.0, so you'll also need to decide which of the two you're targeting. There's some information about the hosting interfaces at the IronPython Cookbook: http://www.ironpython.info/index.php/Main_Page The simplest way to call IronPython from C# today is to define an interface from C# and to have your Python class derive from it. But you'd still have the issue of being able to instantiate the object. On Sun, Oct 5, 2008 at 11:25 AM, wrote: > Hi, > I'm new to IronPythonStudio. I choose this environment in order to create > .NET assemblies (dll) from IronPython code and use them into a .NET project > (like C#, J# or so). > > I've noticed that some conversions between IP code and compiled dll were > made by IronPythonStudio compiler, for example the names of every > user-defined method change from "methodName" to "MethodName$f19" (a suffix > like "$f" is appended)..no problems about that. > > The convertion that is causing me a lot of troubles is about method > parameters. > Example: if my init method was: > __init__(self, n, s, m) > after compilation becomes: > __init__$f0(FunctionEnvironment16Dictionary _env, Object self, Object n, > Object s, Object m) > > Well, where should i get the correct instance of > FunctionEnvironment16Dictionary? > > If i create a new object of this type and try to invoke init in this way: > (now we are into a C# project) > > Student stu2 = new Student(); > stu2.__init__$f0(new FunctionEnvironment16Dictionary(), stu2, "hello", > "world", "!!!"); > > the system always throw a NullReferenceException in the second line.. Here > is the stack trace: > > at IronPython.Runtime.Calls.FunctionEnvironmentDictionary.get_Module() > at IronPython.Runtime.Operations.Ops.UpdateTraceBack(ICallerContext > context, String filename, Int32 line, String funcName, Boolean& notHandled) > at Student.__init__$f0(FunctionEnvironment16Dictionary $env, Object self, > Object n, Object s, Object m) > at System.AppDomain._nExecuteAssembly(Assembly assembly, String[] args) > at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence > assemblySecurity, String[] args) > at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() > at System.Threading.ThreadHelper.ThreadStart_Context(Object state) > at System.Threading.ExecutionContext.Run(ExecutionContext > executionContext, ContextCallback callback, Object state) > at System.Threading.ThreadHelper.ThreadStart() > > Seems that a Module is required but i don't understand what should i do... > > Someone could explain where is my mistake? > > Thanks a lot!! > Marco > ---- Nuova grafica e nuove funzionalit?! Crea subito Gratis la tua nuova > Casella di Posta Katamail > _______________________________________________ > 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 acangiano at gmail.com Sun Oct 5 23:17:00 2008 From: acangiano at gmail.com (Antonio Cangiano) Date: Sun, 5 Oct 2008 17:17:00 -0400 Subject: [IronPython] Do you use IronPython Studio? Message-ID: <309e18020810051417t4840f68bkbe267c900bb8aed6@mail.gmail.com> Hello, I tried IronPython Studio and found fundamental flaws that make programming with it far from enjoyable. Amongst the annoyances are the lack of automatic indentation and the fact that the IntelliSense fails to propose a list of properties for a given control. More severely, I noticed that the IDE wipes out all the code already written by the developer, if you double click on a particular event within the Properties window for a control. Also, if you double click on a particular event in the same window, and then remove the code for handling the event, in Designer mode you will no longer see the UI you had laid out, but just a basic form. My question to the IronPython community is, what do you use? Do you all use IronPython Studio for designing the UI and then hack away the business logic with your favorite editor? If so, I think that the current shortcomings of the IDE may negatively affect the adoption of IronPython itself. I enjoy Python programming much more than I enjoy C# programming, but after an hour long session with IronPython Studio I was longing for the comfort of using the C# IDE. Thanks in advance, Antonio -- http://antoniocangiano.com - Zen and the Art of Programming http://math-blog.com - Mathematics is wonderful! http://stacktrace.it - Aperiodico di resistenza informatica Currently writing "Ruby on Rails for Microsoft Developers" for Wrox. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olegtk at microsoft.com Sun Oct 5 23:24:02 2008 From: olegtk at microsoft.com (Oleg Tkachenko) Date: Sun, 5 Oct 2008 14:24:02 -0700 Subject: [IronPython] Do you use IronPython Studio? In-Reply-To: <309e18020810051417t4840f68bkbe267c900bb8aed6@mail.gmail.com> References: <309e18020810051417t4840f68bkbe267c900bb8aed6@mail.gmail.com> Message-ID: I should note that IronPython Studio 1.0 is basically Visual Studio SDK sample whose goal was to demonstrate language integration in Visual Studio. As such it's obvious why its development experience is far from perfect. We are currently working on making IronPython Studio a real product. -- Oleg From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Antonio Cangiano Sent: Sunday, October 05, 2008 2:17 PM To: users at lists.ironpython.com Subject: [IronPython] Do you use IronPython Studio? Hello, I tried IronPython Studio and found fundamental flaws that make programming with it far from enjoyable. Amongst the annoyances are the lack of automatic indentation and the fact that the IntelliSense fails to propose a list of properties for a given control. More severely, I noticed that the IDE wipes out all the code already written by the developer, if you double click on a particular event within the Properties window for a control. Also, if you double click on a particular event in the same window, and then remove the code for handling the event, in Designer mode you will no longer see the UI you had laid out, but just a basic form. My question to the IronPython community is, what do you use? Do you all use IronPython Studio for designing the UI and then hack away the business logic with your favorite editor? If so, I think that the current shortcomings of the IDE may negatively affect the adoption of IronPython itself. I enjoy Python programming much more than I enjoy C# programming, but after an hour long session with IronPython Studio I was longing for the comfort of using the C# IDE. Thanks in advance, Antonio -- http://antoniocangiano.com - Zen and the Art of Programming http://math-blog.com - Mathematics is wonderful! http://stacktrace.it - Aperiodico di resistenza informatica Currently writing "Ruby on Rails for Microsoft Developers" for Wrox. -------------- next part -------------- An HTML attachment was scrubbed... URL: From acangiano at gmail.com Sun Oct 5 23:59:20 2008 From: acangiano at gmail.com (Antonio Cangiano) Date: Sun, 5 Oct 2008 17:59:20 -0400 Subject: [IronPython] Do you use IronPython Studio? In-Reply-To: References: <309e18020810051417t4840f68bkbe267c900bb8aed6@mail.gmail.com> Message-ID: <309e18020810051459ma803681n41b1b3fe92096f28@mail.gmail.com> On Sun, Oct 5, 2008 at 5:24 PM, Oleg Tkachenko wrote: > We are currently working on making IronPython Studio a real product. Thanks, Oleg. That's very encouraging. Cheers, Antonio -- http://antoniocangiano.com - Zen and the Art of Programming http://math-blog.com - Mathematics is wonderful! http://stacktrace.it - Aperiodico di resistenza informatica Currently writing "Ruby on Rails for Microsoft Developers" for Wrox. From nytrokiss at gmail.com Mon Oct 6 04:03:30 2008 From: nytrokiss at gmail.com (James Matthews) Date: Sun, 5 Oct 2008 19:03:30 -0700 Subject: [IronPython] Do you use IronPython Studio? In-Reply-To: <309e18020810051459ma803681n41b1b3fe92096f28@mail.gmail.com> References: <309e18020810051417t4840f68bkbe267c900bb8aed6@mail.gmail.com> <309e18020810051459ma803681n41b1b3fe92096f28@mail.gmail.com> Message-ID: <8a6b8e350810051903i713360bei74c5c9656fb31c44@mail.gmail.com> I think it's a great start. VS is a great IDE and i love writing in C# with it. However it has room to improve On Sun, Oct 5, 2008 at 2:59 PM, Antonio Cangiano wrote: > On Sun, Oct 5, 2008 at 5:24 PM, Oleg Tkachenko > wrote: > > We are currently working on making IronPython Studio a real product. > > Thanks, Oleg. That's very encouraging. > > Cheers, > Antonio > -- > http://antoniocangiano.com - Zen and the Art of Programming > http://math-blog.com - Mathematics is wonderful! > http://stacktrace.it - Aperiodico di resistenza informatica > Currently writing "Ruby on Rails for Microsoft Developers" for Wrox. > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.goldwatches.com/ http://www.jewelerslounge.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From seob at gmx.ch Mon Oct 6 06:09:23 2008 From: seob at gmx.ch (Severin) Date: Mon, 6 Oct 2008 06:09:23 +0200 Subject: [IronPython] concurrent list access In-Reply-To: References: Message-ID: Hello, I have a problem with lists. Taking a quick look to the IronPython list implementation they intend to be thread safe (I guess). now I made a quicksort example that sorts a list in place using threads. its a divide and conquer approach and at a certain level the list ist just sorted using the sort function. for some reason it doesn't work on ironpython (2.0B5 on Vista, quad-core) sometimes. so: - can my concurrent list access corrupt the list? (especially the slice operator) - can anybody see another problem here? any hint is appreciated Severin here is the code: ----- import threading threads = [] def partition(array, begin, end): while begin < end: while begin < end: if array[begin] > array[end]: (array[begin], array[end]) = (array[end], array[begin]) break end -= 1 while begin < end: if array[begin] > array[end]: (array[begin], array[end]) = (array[end], array[begin]) break begin += 1 return begin def quicksort(array, begin, end): if begin < end: if end - begin <= 2**12: #print "%d %d" % (begin, end) sorted = [x for x in array[begin:end]] sorted.sort() array[begin:end] = sorted else: split = partition(array, begin, end-1) thread = threading.Thread(target=quicksort, args=(array, begin, split,)) thread.start() threads.append(thread) thread = threading.Thread(target=quicksort, args=(array, split+1, end)) thread.start() threads.append(thread) if __name__ == '__main__': import random # settings n = 2**14 # setup l = range(n) random.shuffle(l) # sort quicksort(l, 0, len(l)) # join for thread in threads: thread.join() # test for i in range(n): if i != l[i]: print 'failure %d != %d' % (i, l[i]) print 'done' -------------- next part -------------- An HTML attachment was scrubbed... URL: From deus.verus at gmail.com Mon Oct 6 06:23:45 2008 From: deus.verus at gmail.com (Serge) Date: Mon, 6 Oct 2008 14:23:45 +1000 Subject: [IronPython] Serializing IronPython classes Message-ID: <18c139230810052123h954b8b6i60f76278e8dcb18e@mail.gmail.com> I've run into problems with serialization. I have a serializable class defined in C# which gets extended from IP, however when I try to serialize a collection of both parent and child instances, I get an exception saying that the IP generated class is not marked as serializable. With the lack of attributes, I am guessing I must do something else to enable serialization? Regards, Serge. -------------- next part -------------- An HTML attachment was scrubbed... URL: From desleo at gmail.com Mon Oct 6 06:57:02 2008 From: desleo at gmail.com (Leo Carbajal) Date: Sun, 5 Oct 2008 23:57:02 -0500 Subject: [IronPython] Syntax Checking In-Reply-To: <350E7D38B6D819428718949920EC2355478913AA1C@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <350E7D38B6D819428718949920EC2355478913AA1C@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: Thanks for the helpful info, as always. This latest release has made it possible, at last, to run my code in a neat little restricted sandbox. As part of my never ending quest to provide a "safe"(tm) scripting environment for my app, I've finally boiled down the boilerplate of the hosting model to feature the following function (not counting all the engine setup). My question centers around the way I compile and "cache" the code. Realistically, most of the scripts the app will be running will be edited a handful of times as they're tested and then more or less left alone, one issue though is that there could potentially be hundreds of them. Will that cause any issues with memory or performance? Compiling the scripts rather than intepreting them every time provides a tremendous (and obvious) performance gain for all future execution of the scripts. In short, my question is: am I doing something dumb here? private static Dictionary codeCache = new Dictionary(); public static void RunPublicScript(FileInfo script, ScriptScope scope) { try { if (script.LastWriteTime > script.LastAccessTime || !codeCache.ContainsKey(script.FullName)) { string sourceContent = File.ReadAllText(script.FullName); ScriptSource source = publicEngine.CreateScriptSourceFromString(sourceContent, SourceCodeKind.Statements); codeCache[script.FullName] = source.Compile(ErrorReporter); if (ErrorReporter.Errors.Count > 0) { throw new InvalidImplementationException(ErrorReporter.ListErrors()); } codeCache[script.FullName].Execute(scope); script.LastAccessTime = script.LastWriteTime; return; } CompiledCode chunk; if (codeCache.TryGetValue(script.FullName, out chunk)) chunk.Execute(scope); } catch (InvalidImplementationException synError) { throw synError; } catch (Exception ex) { throw ex; } } I may run the Execute() commands in a separate thread, later, to protect against infinite loops - but I want to get more of the application up and running before trying such worst-case scenarios. On Thu, Oct 2, 2008 at 3:28 PM, Dino Viehland wrote: > In 2.0 you can call GetCodeProperties on a ScriptSource and it'll give > you an indication of how the code is. You can also call > ScriptSource.Compile w/ an ErrorListener which can get more detailed > information about the failures. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Leo Carbajal > *Sent:* Thursday, October 02, 2008 1:10 PM > *To:* Users at lists.ironpython.com > *Subject:* [IronPython] Syntax Checking > > > > Is there any way to check the syntax of a script without actually running > the script? Akin to the way VStudio does the 'code smells' nowadays. > > Of course, by 'any way' I'm probably asking if there's an 'easy way', but > I'll take the hard way, too, if it's something I can figure out and re-use. > > --- > V > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Mon Oct 6 07:41:39 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Sun, 5 Oct 2008 22:41:39 -0700 Subject: [IronPython] concurrent list access In-Reply-To: References: Message-ID: Looking at the code, I believe that it's possible for slice-assignment to cause a problem with multiple threads. (In fact, there's a comment there that says "// race is tolerable...".) I suspect that the operation could be made more thread-safe by incorporating the following logic: 1) If the source of the assignment is user-defined type, incur the extra expense of copying that collection into a local list. 2) Hold a lock for the entire time that the target list is mutated. This would involve a performance hit when the source is a user-defined type -- oh, well. You can try to confirm this hypothesis by replacing the slice-assignment with a loop that replaces the values one at a time. If making this change prevents the problem, then the slice-assignment is indeed at fault and you should file a problem report on CodePlex at http://www.codeplex.com/IronPython/WorkItem/List.aspx On Sun, Oct 5, 2008 at 9:09 PM, Severin wrote: > Hello, > I have a problem with lists. > > Taking a quick look to the IronPython list implementation they intend to be > thread safe (I guess). now I made a quicksort example that sorts a list in > place using threads. its a divide and conquer approach and at a certain > level the list ist just sorted using the sort function. > > for some reason it doesn't work on ironpython (2.0B5 on Vista, quad-core) > sometimes. > > so: > - can my concurrent list access corrupt the list? (especially the slice > operator) > - can anybody see another problem here? > > any hint is appreciated > > Severin > > here is the code: > ----- > import threading > > threads = [] > > def partition(array, begin, end): > while begin < end: > while begin < end: > if array[begin] > array[end]: > (array[begin], array[end]) = (array[end], array[begin]) > break > end -= 1 > while begin < end: > if array[begin] > array[end]: > (array[begin], array[end]) = (array[end], array[begin]) > break > begin += 1 > return begin > > > def quicksort(array, begin, end): > if begin < end: > > if end - begin <= 2**12: > #print "%d %d" % (begin, end) > sorted = [x for x in array[begin:end]] > sorted.sort() > array[begin:end] = sorted > else: > > split = partition(array, begin, end-1) > > thread = threading.Thread(target=quicksort, args=(array, > begin, split,)) > thread.start() > threads.append(thread) > > thread = threading.Thread(target=quicksort, args=(array, > split+1, end)) > thread.start() > threads.append(thread) > > > > if __name__ == '__main__': > > import random > > # settings > n = 2**14 > > # setup > l = range(n) > random.shuffle(l) > > # sort > quicksort(l, 0, len(l)) > > # join > for thread in threads: > thread.join() > > # test > for i in range(n): > if i != l[i]: > print 'failure %d != %d' % (i, l[i]) > > print 'done' > > > _______________________________________________ > 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 janrou at gmail.com Mon Oct 6 09:11:33 2008 From: janrou at gmail.com (Jan R) Date: Mon, 6 Oct 2008 09:11:33 +0200 Subject: [IronPython] Do you use IronPython Studio? In-Reply-To: <309e18020810051417t4840f68bkbe267c900bb8aed6@mail.gmail.com> References: <309e18020810051417t4840f68bkbe267c900bb8aed6@mail.gmail.com> Message-ID: Hi, You are right it is not mature. I use it, because the editing and project handling is ok. I have obstructed a lot features in order to have it work: - The project management is good as usual. - The genereated code is not good, so I have obstructed it too. - The editing is ok - Intellisense is stopped. - Tabs ar set to 30 spaces, so I can see the wrong indentions. - It is possible to debug your own code ignoring with patience a lot of code not debuggable. - Two windows can be open at the same as in Emacs C-x, C-2 - Produce compiled Python, which can not be used from the Ipy interpreter. Missing features: - Correct intellisense including correct indention. - Go to defintion should work. - Debugger have to step over silenty undebuggable IronPython code in external assemblies. - The design should produce correct and editable IronPython code. - A way to interact with running windows.forms once Application.Run() is called, you can not give any python commands. I have found it reasonable to write small interactive test with JEdit using the Ipy.exe python interpreter on the side (import module - run test C-Z exit). Looking forward to a new version og the Studio, but the people behind are busy earning money. Regards Jan R. 2008/10/5 Antonio Cangiano > Hello, > > I tried IronPython Studio and found fundamental flaws that make programming > with it far from enjoyable. Amongst the annoyances are the lack of automatic > indentation and the fact that the IntelliSense fails to propose a list of > properties for a given control. More severely, I noticed that the IDE wipes > out all the code already written by the developer, if you double click on a > particular event within the Properties window for a control. Also, if you > double click on a particular event in the same window, and then remove the > code for handling the event, in Designer mode you will no longer see the UI > you had laid out, but just a basic form. > > My question to the IronPython community is, what do you use? Do you all use > IronPython Studio for designing the UI and then hack away the business logic > with your favorite editor? If so, I think that the current shortcomings of > the IDE may negatively affect the adoption of IronPython itself. I enjoy > Python programming much more than I enjoy C# programming, but after an hour > long session with IronPython Studio I was longing for the comfort of using > the C# IDE. > > Thanks in advance, > Antonio > -- > http://antoniocangiano.com - Zen and the Art of Programming > http://math-blog.com - Mathematics is wonderful! > http://stacktrace.it - Aperiodico di resistenza informatica > Currently writing "Ruby on Rails for Microsoft Developers" for Wrox. > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- Med venlig hilsen Jan Rouvillain -------------- next part -------------- An HTML attachment was scrubbed... URL: From seob at gmx.ch Mon Oct 6 10:39:48 2008 From: seob at gmx.ch (Severin) Date: Mon, 6 Oct 2008 10:39:48 +0200 Subject: [IronPython] concurrent list access In-Reply-To: References: Message-ID: I think you are right. Not using the slice operator doesn't give the wrong output anymore. Take a look at the implementation it's clear that this doesn't work like this because the list is copied in 3 steps and the lock is released in between. this means that concurrent slice updates results in loosing some of the new values. On Mon, Oct 6, 2008 at 7:41 AM, Curt Hagenlocher wrote: > Looking at the code, I believe that it's possible for slice-assignment to > cause a problem with multiple threads. (In fact, there's a comment there > that says "// race is tolerable...".) I suspect that the operation could be > made more thread-safe by incorporating the following logic: > 1) If the source of the assignment is user-defined type, incur the extra > expense of copying that collection into a local list. > 2) Hold a lock for the entire time that the target list is mutated. > > This would involve a performance hit when the source is a user-defined type > -- oh, well. > > You can try to confirm this hypothesis by replacing the slice-assignment > with a loop that replaces the values one at a time. If making this change > prevents the problem, then the slice-assignment is indeed at fault and you > should file a problem report on CodePlex at > http://www.codeplex.com/IronPython/WorkItem/List.aspx > > On Sun, Oct 5, 2008 at 9:09 PM, Severin wrote: > >> Hello, >> I have a problem with lists. >> >> Taking a quick look to the IronPython list implementation they intend to >> be thread safe (I guess). now I made a quicksort example that sorts a list >> in place using threads. its a divide and conquer approach and at a certain >> level the list ist just sorted using the sort function. >> >> for some reason it doesn't work on ironpython (2.0B5 on Vista, quad-core) >> sometimes. >> >> so: >> - can my concurrent list access corrupt the list? (especially the slice >> operator) >> - can anybody see another problem here? >> >> any hint is appreciated >> >> Severin >> >> here is the code: >> ----- >> import threading >> >> threads = [] >> >> def partition(array, begin, end): >> while begin < end: >> while begin < end: >> if array[begin] > array[end]: >> (array[begin], array[end]) = (array[end], >> array[begin]) >> break >> end -= 1 >> while begin < end: >> if array[begin] > array[end]: >> (array[begin], array[end]) = (array[end], >> array[begin]) >> break >> begin += 1 >> return begin >> >> >> def quicksort(array, begin, end): >> if begin < end: >> >> if end - begin <= 2**12: >> #print "%d %d" % (begin, end) >> sorted = [x for x in array[begin:end]] >> sorted.sort() >> array[begin:end] = sorted >> else: >> >> split = partition(array, begin, end-1) >> >> thread = threading.Thread(target=quicksort, args=(array, >> begin, split,)) >> thread.start() >> threads.append(thread) >> >> thread = threading.Thread(target=quicksort, args=(array, >> split+1, end)) >> thread.start() >> threads.append(thread) >> >> >> >> if __name__ == '__main__': >> >> import random >> >> # settings >> n = 2**14 >> >> # setup >> l = range(n) >> random.shuffle(l) >> >> # sort >> quicksort(l, 0, len(l)) >> >> # join >> for thread in threads: >> thread.join() >> >> # test >> for i in range(n): >> if i != l[i]: >> print 'failure %d != %d' % (i, l[i]) >> >> print 'done' >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony_caduto at amsoftwaredesign.com Mon Oct 6 16:33:52 2008 From: tony_caduto at amsoftwaredesign.com (Tony Caduto) Date: Mon, 06 Oct 2008 09:33:52 -0500 Subject: [IronPython] Do you use IronPython Studio? In-Reply-To: <309e18020810051417t4840f68bkbe267c900bb8aed6@mail.gmail.com> References: <309e18020810051417t4840f68bkbe267c900bb8aed6@mail.gmail.com> Message-ID: <48EA21D0.9000504@amsoftwaredesign.com> Antonio Cangiano wrote: > Hello, > > I tried IronPython Studio and found fundamental flaws that make > programming with it far from enjoyable. Amongst the annoyances are the > lack of automatic indentation and the fact that the IntelliSense fails > to propose a list of properties for a given control. More severely, I > noticed that the IDE wipes out all the code already written by the > developer, if you double click on a particular event within the > Properties window for a control. Also, if you double click on a > particular event in the same window, and then remove the code for > handling the event, in Designer mode you will no longer see the UI you > had laid out, but just a basic form. > > My question to the IronPython community is, what do you use? Do you > all use IronPython Studio for designing the UI and then hack away the > business logic with your favorite editor? If so, I think that the > current shortcomings of the IDE may negatively affect the adoption of > IronPython itself. I enjoy Python programming much more than I enjoy > C# programming, but after an hour long session with IronPython Studio > I was longing for the comfort of using the C# IDE. > IronPython Studio (IPS) is really bad IMHO. I use Pyscripter (http://pyscripter.googlepages.com/) and if I need to run under IronPython I make the changes needed (if any) and then run with IronPython. Pyscripter is the best Python IDE I have tried, it does have a few quirks and flaws but is miles better than IronPython Studio. Another nice thing about Pyscripter is it's built with Delphi so it's native compiled and fast, and again because its compiled with Delphi it's a single exe (9mb) with no dependencies, compare that with the huge footprint and dependencies with IPS. Because Pyscripter is so small you can simple copy it to a server(debugger only works with Cpython) for debugging and delete it when finished. From dinov at microsoft.com Mon Oct 6 18:08:11 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 6 Oct 2008 09:08:11 -0700 Subject: [IronPython] Serializing IronPython classes In-Reply-To: <18c139230810052123h954b8b6i60f76278e8dcb18e@mail.gmail.com> References: <18c139230810052123h954b8b6i60f76278e8dcb18e@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355478913B34B@NA-EXMSG-C102.redmond.corp.microsoft.com> I would strongly encourage you to use cPickle or pickle instead of .NET serialization. In 2.0 all .NET serializable types can also be pickled - they define __reduce_ex__ which handles this. First off we should be setting the serializable bit on subclasses that are serializable - that's just a bug that we're not doing that. But once we've done that the problem w/ .NET serialization is that ultimately we need a static method or type that we can point at that does the deserialization. For a user defined type in Python we will need to be able to deserialize the type, the module the type lives in, and presumably even the ScriptRuntime which holds the module. Pickle handles this by serializing the module & type name but w/o a ScriptRuntime we couldn't even get at that. We might have been able to require a ScriptRuntime to be smuggled in the StreamingContext but it's not clear that it would work well. So if you really want .NET serialization we can fix the bug - but you'll need to implement ISerializable and figure out some way to deal getting the class, module, and runtime information saved/restored yourself. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Serge Sent: Sunday, October 05, 2008 9:24 PM To: users at lists.ironpython.com Subject: [IronPython] Serializing IronPython classes I've run into problems with serialization. I have a serializable class defined in C# which gets extended from IP, however when I try to serialize a collection of both parent and child instances, I get an exception saying that the IP generated class is not marked as serializable. With the lack of attributes, I am guessing I must do something else to enable serialization? Regards, Serge. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Oct 7 04:04:54 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 6 Oct 2008 19:04:54 -0700 Subject: [IronPython] Yield Prolog Benchmarks In-Reply-To: <5b0248170810050021v7f4811cs63631baa1dde1fde@mail.gmail.com> References: <5b0248170810050021v7f4811cs63631baa1dde1fde@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355478913B7B3@NA-EXMSG-C102.redmond.corp.microsoft.com> I took a look and we're spending most of our time doing old instance/old class accesses. If they used new-style classes it would probably run faster - although CPython might as well :) It seems like a good chunk of that is coming from __eq__/__cmp__ on the old-style classes - and w/ new-style classes we can make that really fast. There's definitely some fat that can be trimmed here though - we currently have an extra layer of indirection when looking up the class vars which is just legacy of the DLR changing under us in interesting ways. We could also look at specifically tuning old class dictionaries - currently we only have a special dict for old instances dictionaries. But I suspect we'll look at tuning new-style classes more first. One possible thing which could be hitting Mono would be the use of our Dictionary. That relies on having IEquatable working well. But maybe not, I just say that because we hit those dictionaries a lot. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon Sent: Sunday, October 05, 2008 12:21 AM To: Discussion of IronPython Subject: [IronPython] Yield Prolog Benchmarks Yield Prolog is an embeddable Prolog implementation that compiles to Python, C#, or JavaScript using "yield" statements in those languages. http://yieldprolog.sourceforge.net/ It comes with a nice benchmark calculating 2680 solutions of 11-queens problem in Prolog. So I tried it out of curiosity. http://yieldprolog.sourceforge.net/benchmarks.html How to run: svn co https://yieldprolog.svn.sourceforge.net/svnroot/yieldprolog/YieldProlog yieldprolog cd yieldprolog/source/python # Edit Compiler.py to comment out "from compiler import *". It is not needed. cd examples/Benchmarks python queens.py Intel Core 2 T7200 2.00GHz 2.00GB RAM Microsoft Windows XP Home Edition SP2 Python 2.5.1 36.2195480152 36.3135356589 36.0008464763 IronPython 2.0 Beta 5 on .NET Framework 3.5 SP1 52.5789892291 53.0868051666 53.0352047537 In this particular benchmark, IronPython 2 comes about 30% slower than Python 2.5. Mono is much, much slower than .NET for this particular benchmark, by the way. I am investigating. -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From deus.verus at gmail.com Tue Oct 7 04:36:22 2008 From: deus.verus at gmail.com (Serge) Date: Tue, 7 Oct 2008 12:36:22 +1000 Subject: [IronPython] Serializing IronPython classes In-Reply-To: <350E7D38B6D819428718949920EC2355478913B34B@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <18c139230810052123h954b8b6i60f76278e8dcb18e@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B34B@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <18c139230810061936q22a04d27xa6a5c116b8415c73@mail.gmail.com> Thanks for the heads up, however trying to use cPickle, I still get the error saying that the child class is not marked as serializable..? On 10/7/08, Dino Viehland wrote: > > I would strongly encourage you to use cPickle or pickle instead of .NET > serialization. In 2.0 all .NET serializable types can also be pickled ? > they define __reduce_ex__ which handles this. > > > > First off we should be setting the serializable bit on subclasses that are > serializable ? that's just a bug that we're not doing that. But once we've > done that the problem w/ .NET serialization is that ultimately we need a > static method or type that we can point at that does the deserialization. > For a user defined type in Python we will need to be able to deserialize the > type, the module the type lives in, and presumably even the ScriptRuntime > which holds the module. Pickle handles this by serializing the module & > type name but w/o a ScriptRuntime we couldn't even get at that. We might > have been able to require a ScriptRuntime to be smuggled in the > StreamingContext but it's not clear that it would work well. > > > > So if you really want .NET serialization we can fix the bug ? but you'll > need to implement ISerializable and figure out some way to deal getting the > class, module, and runtime information saved/restored yourself. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Serge > *Sent:* Sunday, October 05, 2008 9:24 PM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Serializing IronPython classes > > > > I've run into problems with serialization. I have a serializable class > defined in C# which gets extended from IP, however when I try to serialize a > collection of both parent and child instances, I get an exception saying > that the IP generated class is not marked as serializable. > > With the lack of attributes, I am guessing I must do something else to > enable serialization? > > Regards, Serge. > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Oct 7 04:49:33 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 6 Oct 2008 19:49:33 -0700 Subject: [IronPython] Serializing IronPython classes In-Reply-To: <18c139230810061936q22a04d27xa6a5c116b8415c73@mail.gmail.com> References: <18c139230810052123h954b8b6i60f76278e8dcb18e@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B34B@NA-EXMSG-C102.redmond.corp.microsoft.com> <18c139230810061936q22a04d27xa6a5c116b8415c73@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355478913B7C8@NA-EXMSG-C102.redmond.corp.microsoft.com> Ahh, that sounds like a bad bug, but I think I know what's causing it - we're hitting the new.NET serialization support because __reduce_ex__ is now defined for you :) Can you add an override that dispatches __reduce_ex__ to the object version, eg: def __reduce_ex__(self, *args): return object.__reduce_ex__(self, *args) We should probably do that automatically for user-defined instances which should be easy to do if this works for you. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Serge Sent: Monday, October 06, 2008 7:36 PM To: Discussion of IronPython Subject: Re: [IronPython] Serializing IronPython classes Thanks for the heads up, however trying to use cPickle, I still get the error saying that the child class is not marked as serializable..? On 10/7/08, Dino Viehland > wrote: I would strongly encourage you to use cPickle or pickle instead of .NET serialization. In 2.0 all .NET serializable types can also be pickled - they define __reduce_ex__ which handles this. First off we should be setting the serializable bit on subclasses that are serializable - that's just a bug that we're not doing that. But once we've done that the problem w/ .NET serialization is that ultimately we need a static method or type that we can point at that does the deserialization. For a user defined type in Python we will need to be able to deserialize the type, the module the type lives in, and presumably even the ScriptRuntime which holds the module. Pickle handles this by serializing the module & type name but w/o a ScriptRuntime we couldn't even get at that. We might have been able to require a ScriptRuntime to be smuggled in the StreamingContext but it's not clear that it would work well. So if you really want .NET serialization we can fix the bug - but you'll need to implement ISerializable and figure out some way to deal getting the class, module, and runtime information saved/restored yourself. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Serge Sent: Sunday, October 05, 2008 9:24 PM To: users at lists.ironpython.com Subject: [IronPython] Serializing IronPython classes I've run into problems with serialization. I have a serializable class defined in C# which gets extended from IP, however when I try to serialize a collection of both parent and child instances, I get an exception saying that the IP generated class is not marked as serializable. With the lack of attributes, I am guessing I must do something else to enable serialization? Regards, Serge. _______________________________________________ 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 deus.verus at gmail.com Tue Oct 7 06:15:01 2008 From: deus.verus at gmail.com (Serge) Date: Tue, 7 Oct 2008 14:15:01 +1000 Subject: [IronPython] Serializing IronPython classes In-Reply-To: <350E7D38B6D819428718949920EC2355478913B7C8@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <18c139230810052123h954b8b6i60f76278e8dcb18e@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B34B@NA-EXMSG-C102.redmond.corp.microsoft.com> <18c139230810061936q22a04d27xa6a5c116b8415c73@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B7C8@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <18c139230810062115p6cbf9e3cq322ee7c857427076@mail.gmail.com> Okay now this is getting interesting. I assumed that the warning was about the child class, but I'm not sure. A bit of info: The parent C# class is called Object. I did the override on on __reduce_ex__ as you suggested but trying to pickle still produced the same error: Type 'IronPython.NewTypes.Engine.Object_1$2' in Assembly 'Snippets.scripting, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' is not marked as serializable. For curiosity, I called __reduce_ex__ on a child instance and got the following error: expected Vector2, got Object_1$2 There are several Microsoft.Xna.Framework.Vector2 members and it looks like they're being replaced by this Object_1$2 which I assumed at first to be the child class because of its name. __reduce_ex__ on the parent instances works fine. I'm out of my depth here so I can't give more meaningful information. On 10/7/08, Dino Viehland wrote: > > Ahh, that sounds like a bad bug, but I think I know what's causing it ? > we're hitting the new.NET serialization support because __reduce_ex__ is now > defined for you J Can you add an override that dispatches __reduce_ex__ > to the object version, eg: > > > > def __reduce_ex__(self, *args): > > return object.__reduce_ex__(self, *args) > > > > We should probably do that automatically for user-defined instances which > should be easy to do if this works for you. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Serge > *Sent:* Monday, October 06, 2008 7:36 PM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Serializing IronPython classes > > > > Thanks for the heads up, however trying to use cPickle, I still get the > error saying that the child class is not marked as serializable..? > > On 10/7/08, *Dino Viehland* wrote: > > I would strongly encourage you to use cPickle or pickle instead of .NET > serialization. In 2.0 all .NET serializable types can also be pickled ? > they define __reduce_ex__ which handles this. > > > > First off we should be setting the serializable bit on subclasses that are > serializable ? that's just a bug that we're not doing that. But once we've > done that the problem w/ .NET serialization is that ultimately we need a > static method or type that we can point at that does the deserialization. > For a user defined type in Python we will need to be able to deserialize the > type, the module the type lives in, and presumably even the ScriptRuntime > which holds the module. Pickle handles this by serializing the module & > type name but w/o a ScriptRuntime we couldn't even get at that. We might > have been able to require a ScriptRuntime to be smuggled in the > StreamingContext but it's not clear that it would work well. > > > > So if you really want .NET serialization we can fix the bug ? but you'll > need to implement ISerializable and figure out some way to deal getting the > class, module, and runtime information saved/restored yourself. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Serge > *Sent:* Sunday, October 05, 2008 9:24 PM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Serializing IronPython classes > > > > I've run into problems with serialization. I have a serializable class > defined in C# which gets extended from IP, however when I try to serialize a > collection of both parent and child instances, I get an exception saying > that the IP generated class is not marked as serializable. > > With the lack of attributes, I am guessing I must do something else to > enable serialization? > > Regards, Serge. > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alecmunro at gmail.com Tue Oct 7 14:56:24 2008 From: alecmunro at gmail.com (Alec Munro) Date: Tue, 7 Oct 2008 09:56:24 -0300 Subject: [IronPython] Can IronPython be used to create COM DLLs? Message-ID: <9819d58b0810070556m50619f14h1de9d654583e883d@mail.gmail.com> Hi List, I'm embarking on a project to rewrite a DLL that my team uses. It's a COM DLL, and has to implement specific interfaces. Currently, it's written in C++, which I am not terribly proficient with. However, it's important that the code is as well tested and stable as possible. As such, I thought it would be worth investigating whether this is something that IronPython could do, as Python is something I'm quite familiar with. So, can IronPython create DLLs that implement specific COM interfaces? Thanks, Alec Munro From asaf at itstructures.com Tue Oct 7 17:15:57 2008 From: asaf at itstructures.com (Asaf Kleinbort) Date: Tue, 7 Oct 2008 17:15:57 +0200 Subject: [IronPython] IPy2b5 Performance Message-ID: <003301c9288f$9bbc67e0$d33537a0$@com> Hi all, I am investigating performance problems we have when running our code using IPy2b5 (comparing to IPy 1.1.1). Found two interesting issues: 1. It seems that there is some bug in the 'sort' method Running the following code: from System import DateTime def test(): s = DateTime.Now for i in xrange(100000): a = [1,4,7,6,10,6] a.sort() return (DateTime.Now - s).TotalMilliseconds print test() we get 3900% (!) degradation between IP1 and IPy2b5: In IPy 1 the code runs in 390ms and in IPy2b5: 15281ms 2.This is probably already known: there is a major difference in performance between an if/else block and a try/catch one: def func1(obj): try: return obj.prop except: return 0 def func2(obj): if hasattr(obj,'prop'): return obj.prop else: return 0 def test(s): for i in xrange(100000): x = func1(set()) return (DateTime.Now -s).TotalMilliseconds def test2(s): for i in xrange(10000): x = func2(set()) return (DateTime.Now -s).TotalMilliseconds print test(DateTime.Now) print test2(DateTime.Now) Results for IPy1 and IPy2b5 are similar ~3000ms for 'test' and ~15ms for 'test2'. Using if/else is 200 times quicker. In Cpython it is only 2 times quicker. We can bypass the second issue in our code, but the first one is harder to ignore. Are these issues already known? Any ideas? Thanks, Asaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Tue Oct 7 17:40:11 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 7 Oct 2008 08:40:11 -0700 Subject: [IronPython] IPy2b5 Performance In-Reply-To: <003301c9288f$9bbc67e0$d33537a0$@com> References: <003301c9288f$9bbc67e0$d33537a0$@com> Message-ID: Every time you call sort, we create a new call site object which needs to be spun up. So your test is really an absolute worst-case as far as performance goes. Is it actually reflective of the circumstances under which you do sorting, where the number of sorts vastly exceeds the size of each sort? We could reuse the sort call site instead of creating a new one for each sort, but that comes with its own problems. Exceptions are relatively slow in the CLR, which is why it's best to use them only for actual exceptions and not for the failure path of a comparison. In the example you give, the "best" code is probably "getattr(obj, 'prop', 0)". On Tue, Oct 7, 2008 at 8:15 AM, Asaf Kleinbort wrote: > Hi all, > > I am investigating performance problems we have when running our code using > IPy2b5 (comparing to IPy 1.1.1). > > Found two interesting issues: > > 1. It seems that there is some bug in the 'sort' method > > Running the following code: > > > > from System import DateTime > > def test(): > > s = DateTime.Now > > for i in xrange(100000): > > a = [1,4,7,6,10,6] > > a.sort() > > return (DateTime.Now - s).TotalMilliseconds > > print test() > > > > we get 3900% (!) degradation between IP1 and IPy2b5: In IPy 1 the code > runs in *390ms* and in IPy2b5: *15281ms* > > > > 2.This is probably already known: there is a major difference in > performance between an if/else block and a try/catch one: > > def func1(obj): > > try: > > return obj.prop > > except: > > return 0 > > > > def func2(obj): > > if hasattr(obj,'prop'): > > return obj.prop > > else: > > return 0 > > > > def test(s): > > for i in xrange(100000): > > x = func1(set()) > > return (DateTime.Now -s).TotalMilliseconds > > > > def test2(s): > > for i in xrange(10000): > > x = func2(set()) > > return (DateTime.Now -s).TotalMilliseconds > > > > print test(DateTime.Now) > > print test2(DateTime.Now) > > * * > > Results for IPy1 and IPy2b5 are similar ~3000ms for 'test' and ~15ms for > 'test2'. Using if/else is 200 times quicker. > > In Cpython it is only 2 times quicker. > > > > We can bypass the second issue in our code, but the first one is harder to > ignore? > > Are these issues already known? Any ideas? > > Thanks, > > Asaf** > > > > > > _______________________________________________ > 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 asaf at itstructures.com Tue Oct 7 17:50:48 2008 From: asaf at itstructures.com (Asaf Kleinbort) Date: Tue, 7 Oct 2008 17:50:48 +0200 Subject: [IronPython] IPy2b5 Performance In-Reply-To: References: <003301c9288f$9bbc67e0$d33537a0$@com> Message-ID: <003e01c92894$797918e0$6c6b4aa0$@com> Thanks for the quick reply. Today we do many 'little' sorts, since we have a sort call in an object's __init__. However we might be able to avoid it. I do not understand what constitutes a distinct call site. Can you give some more details on this? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Tuesday, October 07, 2008 5:40 PM To: Discussion of IronPython Subject: Re: [IronPython] IPy2b5 Performance Every time you call sort, we create a new call site object which needs to be spun up. So your test is really an absolute worst-case as far as performance goes. Is it actually reflective of the circumstances under which you do sorting, where the number of sorts vastly exceeds the size of each sort? We could reuse the sort call site instead of creating a new one for each sort, but that comes with its own problems. Exceptions are relatively slow in the CLR, which is why it's best to use them only for actual exceptions and not for the failure path of a comparison. In the example you give, the "best" code is probably "getattr(obj, 'prop', 0)". On Tue, Oct 7, 2008 at 8:15 AM, Asaf Kleinbort wrote: Hi all, I am investigating performance problems we have when running our code using IPy2b5 (comparing to IPy 1.1.1). Found two interesting issues: 1. It seems that there is some bug in the 'sort' method Running the following code: from System import DateTime def test(): s = DateTime.Now for i in xrange(100000): a = [1,4,7,6,10,6] a.sort() return (DateTime.Now - s).TotalMilliseconds print test() we get 3900% (!) degradation between IP1 and IPy2b5: In IPy 1 the code runs in 390ms and in IPy2b5: 15281ms 2.This is probably already known: there is a major difference in performance between an if/else block and a try/catch one: def func1(obj): try: return obj.prop except: return 0 def func2(obj): if hasattr(obj,'prop'): return obj.prop else: return 0 def test(s): for i in xrange(100000): x = func1(set()) return (DateTime.Now -s).TotalMilliseconds def test2(s): for i in xrange(10000): x = func2(set()) return (DateTime.Now -s).TotalMilliseconds print test(DateTime.Now) print test2(DateTime.Now) Results for IPy1 and IPy2b5 are similar ~3000ms for 'test' and ~15ms for 'test2'. Using if/else is 200 times quicker. In Cpython it is only 2 times quicker. We can bypass the second issue in our code, but the first one is harder to ignore. Are these issues already known? Any ideas? Thanks, Asaf _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Tue Oct 7 18:38:08 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 7 Oct 2008 09:38:08 -0700 Subject: [IronPython] Can IronPython be used to create COM DLLs? In-Reply-To: <9819d58b0810070556m50619f14h1de9d654583e883d@mail.gmail.com> References: <9819d58b0810070556m50619f14h1de9d654583e883d@mail.gmail.com> Message-ID: The short answer to this is "no". I suspect it might be possible to implement predefined COM interfaces from IronPython and to use COM-.NET interop to make this code visible to COM consumers. But to actually create a DLL that can be loaded by the COM loader would require a greater level of control over the bits being produced for the DLL than we currently offer in the precompilation feature. This may be something that the pywin32 extensions to CPython will support. On Tue, Oct 7, 2008 at 5:56 AM, Alec Munro wrote: > Hi List, > > I'm embarking on a project to rewrite a DLL that my team uses. It's a > COM DLL, and has to implement specific interfaces. Currently, it's > written in C++, which I am not terribly proficient with. However, it's > important that the code is as well tested and stable as possible. As > such, I thought it would be worth investigating whether this is > something that IronPython could do, as Python is something I'm quite > familiar with. > > So, can IronPython create DLLs that implement specific COM interfaces? > > Thanks, > Alec Munro > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Tue Oct 7 18:47:36 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 7 Oct 2008 09:47:36 -0700 Subject: [IronPython] IPy2b5 Performance In-Reply-To: <003e01c92894$797918e0$6c6b4aa0$@com> References: <003301c9288f$9bbc67e0$d33537a0$@com> <003e01c92894$797918e0$6c6b4aa0$@com> Message-ID: A dynamic call site is the fundamental unit of dynamic dispatch in the DLR. The first time a call (such as __cmp__) goes through the site, we have to do the work of figuring out exactly what code is going to run. The next time the site is used, if the types of the arguments are the same then the same code is run. So there's a lot of overhead on that first call. On Tue, Oct 7, 2008 at 8:50 AM, Asaf Kleinbort wrote: > Thanks for the quick reply. > > Today we do many 'little' sorts, since we have a sort call in an object's > __init__. However we might be able to avoid it. > > I do not understand what constitutes a distinct call site. Can you give > some more details on this? > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Curt Hagenlocher > *Sent:* Tuesday, October 07, 2008 5:40 PM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] IPy2b5 Performance > > > > Every time you call sort, we create a new call site object which needs to > be spun up. So your test is really an absolute worst-case as far as > performance goes. Is it actually reflective of the circumstances under > which you do sorting, where the number of sorts vastly exceeds the size of > each sort? > > > > We could reuse the sort call site instead of creating a new one for each > sort, but that comes with its own problems. > > > > Exceptions are relatively slow in the CLR, which is why it's best to use > them only for actual exceptions and not for the failure path of a > comparison. In the example you give, the "best" code is probably > "getattr(obj, 'prop', 0)". > > > > On Tue, Oct 7, 2008 at 8:15 AM, Asaf Kleinbort > wrote: > > Hi all, > > I am investigating performance problems we have when running our code using > IPy2b5 (comparing to IPy 1.1.1). > > Found two interesting issues: > > 1. It seems that there is some bug in the 'sort' method > > Running the following code: > > > > from System import DateTime > > def test(): > > s = DateTime.Now > > for i in xrange(100000): > > a = [1,4,7,6,10,6] > > a.sort() > > return (DateTime.Now - s).TotalMilliseconds > > print test() > > > > we get 3900% (!) degradation between IP1 and IPy2b5: In IPy 1 the code > runs in *390ms* and in IPy2b5: *15281ms* > > > > 2.This is probably already known: there is a major difference in > performance between an if/else block and a try/catch one: > > def func1(obj): > > try: > > return obj.prop > > except: > > return 0 > > > > def func2(obj): > > if hasattr(obj,'prop'): > > return obj.prop > > else: > > return 0 > > > > def test(s): > > for i in xrange(100000): > > x = func1(set()) > > return (DateTime.Now -s).TotalMilliseconds > > > > def test2(s): > > for i in xrange(10000): > > x = func2(set()) > > return (DateTime.Now -s).TotalMilliseconds > > > > print test(DateTime.Now) > > print test2(DateTime.Now) > > * * > > Results for IPy1 and IPy2b5 are similar ~3000ms for 'test' and ~15ms for > 'test2'. Using if/else is 200 times quicker. > > In Cpython it is only 2 times quicker. > > > > We can bypass the second issue in our code, but the first one is harder to > ignore? > > Are these issues already known? Any ideas? > > Thanks, > > Asaf > > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Tue Oct 7 18:55:50 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 7 Oct 2008 09:55:50 -0700 Subject: [IronPython] Serializing IronPython classes In-Reply-To: <18c139230810062115p6cbf9e3cq322ee7c857427076@mail.gmail.com> References: <18c139230810052123h954b8b6i60f76278e8dcb18e@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B34B@NA-EXMSG-C102.redmond.corp.microsoft.com> <18c139230810061936q22a04d27xa6a5c116b8415c73@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B7C8@NA-EXMSG-C102.redmond.corp.microsoft.com> <18c139230810062115p6cbf9e3cq322ee7c857427076@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355478926AA53@NA-EXMSG-C102.redmond.corp.microsoft.com> Ok, upon looking into this some more, I'm sad to say it looks like this won't work right now :(. We need to figure out a way to run the serialization for just the base class and how to do that isn't entirely obvious - so it probably won't make 2.0. I've opened a bug to track the issue though: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=18823 Feel free to vote on it so we'll fix it sooner. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Serge Sent: Monday, October 06, 2008 9:15 PM To: Discussion of IronPython Subject: Re: [IronPython] Serializing IronPython classes Okay now this is getting interesting. I assumed that the warning was about the child class, but I'm not sure. A bit of info: The parent C# class is called Object. I did the override on on __reduce_ex__ as you suggested but trying to pickle still produced the same error: Type 'IronPython.NewTypes.Engine.Object_1$2' in Assembly 'Snippets.scripting, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' is not marked as serializable. For curiosity, I called __reduce_ex__ on a child instance and got the following error: expected Vector2, got Object_1$2 There are several Microsoft.Xna.Framework.Vector2 members and it looks like they're being replaced by this Object_1$2 which I assumed at first to be the child class because of its name. __reduce_ex__ on the parent instances works fine. I'm out of my depth here so I can't give more meaningful information. On 10/7/08, Dino Viehland > wrote: Ahh, that sounds like a bad bug, but I think I know what's causing it - we're hitting the new.NET serialization support because __reduce_ex__ is now defined for you :) Can you add an override that dispatches __reduce_ex__ to the object version, eg: def __reduce_ex__(self, *args): return object.__reduce_ex__(self, *args) We should probably do that automatically for user-defined instances which should be easy to do if this works for you. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Serge Sent: Monday, October 06, 2008 7:36 PM To: Discussion of IronPython Subject: Re: [IronPython] Serializing IronPython classes Thanks for the heads up, however trying to use cPickle, I still get the error saying that the child class is not marked as serializable..? On 10/7/08, Dino Viehland > wrote: I would strongly encourage you to use cPickle or pickle instead of .NET serialization. In 2.0 all .NET serializable types can also be pickled - they define __reduce_ex__ which handles this. First off we should be setting the serializable bit on subclasses that are serializable - that's just a bug that we're not doing that. But once we've done that the problem w/ .NET serialization is that ultimately we need a static method or type that we can point at that does the deserialization. For a user defined type in Python we will need to be able to deserialize the type, the module the type lives in, and presumably even the ScriptRuntime which holds the module. Pickle handles this by serializing the module & type name but w/o a ScriptRuntime we couldn't even get at that. We might have been able to require a ScriptRuntime to be smuggled in the StreamingContext but it's not clear that it would work well. So if you really want .NET serialization we can fix the bug - but you'll need to implement ISerializable and figure out some way to deal getting the class, module, and runtime information saved/restored yourself. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Serge Sent: Sunday, October 05, 2008 9:24 PM To: users at lists.ironpython.com Subject: [IronPython] Serializing IronPython classes I've run into problems with serialization. I have a serializable class defined in C# which gets extended from IP, however when I try to serialize a collection of both parent and child instances, I get an exception saying that the IP generated class is not marked as serializable. With the lack of attributes, I am guessing I must do something else to enable serialization? Regards, Serge. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alecmunro at gmail.com Tue Oct 7 18:58:15 2008 From: alecmunro at gmail.com (Alec Munro) Date: Tue, 7 Oct 2008 13:58:15 -0300 Subject: [IronPython] Can IronPython be used to create COM DLLs? In-Reply-To: References: <9819d58b0810070556m50619f14h1de9d654583e883d@mail.gmail.com> Message-ID: <9819d58b0810070958m74b7e06cidb90fcf5b34d9654@mail.gmail.com> Thanks Curt. It would have been a nice solution, but I will make do. Alec On Tue, Oct 7, 2008 at 1:38 PM, Curt Hagenlocher wrote: > The short answer to this is "no". > I suspect it might be possible to implement predefined COM interfaces from > IronPython and to use COM-.NET interop to make this code visible to COM > consumers. But to actually create a DLL that can be loaded by the COM > loader would require a greater level of control over the bits being produced > for the DLL than we currently offer in the precompilation feature. > This may be something that the pywin32 extensions to CPython will support. > > On Tue, Oct 7, 2008 at 5:56 AM, Alec Munro wrote: >> >> Hi List, >> >> I'm embarking on a project to rewrite a DLL that my team uses. It's a >> COM DLL, and has to implement specific interfaces. Currently, it's >> written in C++, which I am not terribly proficient with. However, it's >> important that the code is as well tested and stable as possible. As >> such, I thought it would be worth investigating whether this is >> something that IronPython could do, as Python is something I'm quite >> familiar with. >> >> So, can IronPython create DLLs that implement specific COM interfaces? >> >> Thanks, >> Alec Munro >> _______________________________________________ >> 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 microsoft.com Tue Oct 7 19:56:09 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 7 Oct 2008 10:56:09 -0700 Subject: [IronPython] IPy2b5 Performance In-Reply-To: References: <003301c9288f$9bbc67e0$d33537a0$@com> <003e01c92894$797918e0$6c6b4aa0$@com> Message-ID: <350E7D38B6D819428718949920EC2355478926AAC5@NA-EXMSG-C102.redmond.corp.microsoft.com> FYI after fixing this it looks like 2.0 is about 2x faster on my machine: 10:51:23.06 C:\Product\0\Merlin\Main > ipyr x.py 0.100372393698 10:51:46.32 C:\Product\0\Merlin\Main > C:\Product\Released\IronPython-1.1\ipy.exe x.py 0.222078504391 (note I'm using time.clock() which is more precise than DateTime) If you want to fix this locally you can replace "new DefaultPythonComparer()" in List.sort with DefaultPythonComparer.Instance. I'm planning on doing something a little more involved to avoid having this site go megamorphic in big apps but this should give you a good idea of what the change will do. I should be able to get this in for the release candidate. Thanks for reporting the issue! From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Tuesday, October 07, 2008 9:48 AM To: Discussion of IronPython Subject: Re: [IronPython] IPy2b5 Performance A dynamic call site is the fundamental unit of dynamic dispatch in the DLR. The first time a call (such as __cmp__) goes through the site, we have to do the work of figuring out exactly what code is going to run. The next time the site is used, if the types of the arguments are the same then the same code is run. So there's a lot of overhead on that first call. On Tue, Oct 7, 2008 at 8:50 AM, Asaf Kleinbort > wrote: Thanks for the quick reply. Today we do many 'little' sorts, since we have a sort call in an object's __init__. However we might be able to avoid it. I do not understand what constitutes a distinct call site. Can you give some more details on this? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Tuesday, October 07, 2008 5:40 PM To: Discussion of IronPython Subject: Re: [IronPython] IPy2b5 Performance Every time you call sort, we create a new call site object which needs to be spun up. So your test is really an absolute worst-case as far as performance goes. Is it actually reflective of the circumstances under which you do sorting, where the number of sorts vastly exceeds the size of each sort? We could reuse the sort call site instead of creating a new one for each sort, but that comes with its own problems. Exceptions are relatively slow in the CLR, which is why it's best to use them only for actual exceptions and not for the failure path of a comparison. In the example you give, the "best" code is probably "getattr(obj, 'prop', 0)". On Tue, Oct 7, 2008 at 8:15 AM, Asaf Kleinbort > wrote: Hi all, I am investigating performance problems we have when running our code using IPy2b5 (comparing to IPy 1.1.1). Found two interesting issues: 1. It seems that there is some bug in the 'sort' method Running the following code: from System import DateTime def test(): s = DateTime.Now for i in xrange(100000): a = [1,4,7,6,10,6] a.sort() return (DateTime.Now - s).TotalMilliseconds print test() we get 3900% (!) degradation between IP1 and IPy2b5: In IPy 1 the code runs in 390ms and in IPy2b5: 15281ms 2.This is probably already known: there is a major difference in performance between an if/else block and a try/catch one: def func1(obj): try: return obj.prop except: return 0 def func2(obj): if hasattr(obj,'prop'): return obj.prop else: return 0 def test(s): for i in xrange(100000): x = func1(set()) return (DateTime.Now -s).TotalMilliseconds def test2(s): for i in xrange(10000): x = func2(set()) return (DateTime.Now -s).TotalMilliseconds print test(DateTime.Now) print test2(DateTime.Now) Results for IPy1 and IPy2b5 are similar ~3000ms for 'test' and ~15ms for 'test2'. Using if/else is 200 times quicker. In Cpython it is only 2 times quicker. We can bypass the second issue in our code, but the first one is harder to ignore... Are these issues already known? Any ideas? Thanks, Asaf _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Tue Oct 7 20:49:31 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Wed, 8 Oct 2008 03:49:31 +0900 Subject: [IronPython] Yield Prolog Benchmarks In-Reply-To: <350E7D38B6D819428718949920EC2355478913B7B3@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <5b0248170810050021v7f4811cs63631baa1dde1fde@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B7B3@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <5b0248170810071149xd94247frdcc20afcc601a70f@mail.gmail.com> 2008/10/7 Dino Viehland : > I took a look and we're spending most of our time doing old instance/old class accesses. If they used new-style classes it would probably run faster - although CPython might as well :) It seems like a good chunk of that is coming from __eq__/__cmp__ on the old-style classes - and w/ new-style classes we can make that really fast. Thank you for this insight. Here are numbers with new-style classes. (Just edit Variable.py to let IUnifiable inherit from object.) Python 27.3299986451 27.3397389892 27.3310241944 IronPython 33.4816662453 33.4575162486 33.4634488462 So... yes, with new-style classes IronPython gets faster than CPython with old-style classes, but CPython runs faster with new-style classes as well. Just as you predicted. :) Since this is clearly beneficial, I mailed the author a patch to make old-style->new-style change. -- Seo Sanghyeon From sanxiyn at gmail.com Wed Oct 8 06:48:09 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Wed, 8 Oct 2008 13:48:09 +0900 Subject: [IronPython] Yield Prolog Benchmarks In-Reply-To: <5b0248170810071149xd94247frdcc20afcc601a70f@mail.gmail.com> References: <5b0248170810050021v7f4811cs63631baa1dde1fde@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B7B3@NA-EXMSG-C102.redmond.corp.microsoft.com> <5b0248170810071149xd94247frdcc20afcc601a70f@mail.gmail.com> Message-ID: <5b0248170810072148y3c5c7233s1245d240b46bc2c0@mail.gmail.com> 2008/10/8 Seo Sanghyeon : > Since this is clearly beneficial, I mailed the author a patch to make > old-style->new-style change. It has been applied. http://yieldprolog.svn.sourceforge.net/viewvc/yieldprolog?view=rev&revision=887 -- Seo Sanghyeon From dinov at microsoft.com Wed Oct 8 06:52:57 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 7 Oct 2008 21:52:57 -0700 Subject: [IronPython] Yield Prolog Benchmarks In-Reply-To: <5b0248170810072148y3c5c7233s1245d240b46bc2c0@mail.gmail.com> References: <5b0248170810050021v7f4811cs63631baa1dde1fde@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B7B3@NA-EXMSG-C102.redmond.corp.microsoft.com> <5b0248170810071149xd94247frdcc20afcc601a70f@mail.gmail.com> <5b0248170810072148y3c5c7233s1245d240b46bc2c0@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355478926AE22@NA-EXMSG-C102.redmond.corp.microsoft.com> Cool, it then looks like the next biggest bottleneck is our isinstance implementation (taking about 20% of the time). Certainly seems like something that deserves optimization and I can probably make some easy improvements and get them into 2.0. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon Sent: Tuesday, October 07, 2008 9:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Yield Prolog Benchmarks 2008/10/8 Seo Sanghyeon : > Since this is clearly beneficial, I mailed the author a patch to make > old-style->new-style change. It has been applied. http://yieldprolog.svn.sourceforge.net/viewvc/yieldprolog?view=rev&revision=887 -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From daftspaniel at gmail.com Wed Oct 8 08:34:41 2008 From: daftspaniel at gmail.com (Davy Mitchell) Date: Wed, 8 Oct 2008 07:34:41 +0100 Subject: [IronPython] Problem Importing WinForms IPY2.0 B5 Message-ID: <20253b0c0810072334m5f44aee3s54cb0171f1065a93@mail.gmail.com> Hi All, Basic Repro is... ---------form.py------- import clr clr.AddReference('System.Windows.Forms') from System.Windows.Forms import * print len(dir(Form)) ---------test.py-------- from forms import * print len(dir(Form)) Output: 538 443 My real world case is a subclass of Form is in another module. The module that uses it tries to do mainform.KeyDown += self.DoSomething and fails as KeyDown has vanished. Yet if you copy and paset the subclass Form code into the same file it works! Forgive me if I am missing something obvious in the import mechanism :-) Thanks, Davy Mitchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From daftspaniel at gmail.com Wed Oct 8 14:03:23 2008 From: daftspaniel at gmail.com (Davy Mitchell) Date: Wed, 8 Oct 2008 13:03:23 +0100 Subject: [IronPython] Problem Importing WinForms IPY2.0 B5 In-Reply-To: <20253b0c0810072334m5f44aee3s54cb0171f1065a93@mail.gmail.com> References: <20253b0c0810072334m5f44aee3s54cb0171f1065a93@mail.gmail.com> Message-ID: <20253b0c0810080503s2461e960w5213f34c91d46105@mail.gmail.com> Same code on IP 1.1.2 outputs:699 696 Cheers, Davy On Wed, Oct 8, 2008 at 7:34 AM, Davy Mitchell wrote: > Hi All, > Basic Repro is... > > ---------form.py------- > import clr > clr.AddReference('System.Windows.Forms') > from System.Windows.Forms import * > print len(dir(Form)) > ---------test.py-------- > from forms import * > print len(dir(Form)) > > Output: > 538 > 443 > > My real world case is a subclass of Form is in another module. The module > that uses it tries to do mainform.KeyDown += self.DoSomething and fails as > KeyDown has vanished. > Yet if you copy and paset the subclass Form code into the same file it > works! > > Forgive me if I am missing something obvious in the import mechanism :-) > > Thanks, > Davy Mitchell > -------------- next part -------------- An HTML attachment was scrubbed... URL: From deus.verus at gmail.com Wed Oct 8 15:05:54 2008 From: deus.verus at gmail.com (Serge) Date: Wed, 8 Oct 2008 23:05:54 +1000 Subject: [IronPython] Serializing IronPython classes In-Reply-To: <350E7D38B6D819428718949920EC2355478926AA53@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <18c139230810052123h954b8b6i60f76278e8dcb18e@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B34B@NA-EXMSG-C102.redmond.corp.microsoft.com> <18c139230810061936q22a04d27xa6a5c116b8415c73@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B7C8@NA-EXMSG-C102.redmond.corp.microsoft.com> <18c139230810062115p6cbf9e3cq322ee7c857427076@mail.gmail.com> <350E7D38B6D819428718949920EC2355478926AA53@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <18c139230810080605g17584ec6j6cedc0fa276b26ee@mail.gmail.com> Fair enough, thanks. Any suggestions on how to work around this in the meantime? On 10/8/08, Dino Viehland wrote: > > Ok, upon looking into this some more, I'm sad to say it looks like this > won't work right now L. We need to figure out a way to run the > serialization for just the base class and how to do that isn't entirely > obvious ? so it probably won't make 2.0. I've opened a bug to track the > issue though: > http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=18823 > Feel free to vote on it so we'll fix it sooner. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Serge > *Sent:* Monday, October 06, 2008 9:15 PM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Serializing IronPython classes > > > > Okay now this is getting interesting. I assumed that the warning was about > the child class, but I'm not sure. A bit of info: The parent C# class is > called Object. I did the override on on __reduce_ex__ as you suggested > but trying to pickle still produced the same error: > > Type 'IronPython.NewTypes.Engine.Object_1$2' in Assembly > 'Snippets.scripting, Version=0.0.0.0, Culture=neutral, > PublicKeyToken=null' is not marked as serializable. > > For curiosity, I called __reduce_ex__ on a child instance and > got the following error: expected Vector2, got Object_1$2 > > There are several Microsoft.Xna.Framework.Vector2 members and it looks like > they're being replaced by this Object_1$2 which I assumed at first to be the > child class because of its name. > __reduce_ex__ on the parent instances works fine. I'm out of my depth here > so I can't give more meaningful information. > > On 10/7/08, *Dino Viehland* wrote: > > Ahh, that sounds like a bad bug, but I think I know what's causing it ? > we're hitting the new.NET serialization support because __reduce_ex__ is now > defined for you J Can you add an override that dispatches __reduce_ex__ > to the object version, eg: > > > > def __reduce_ex__(self, *args): > > return object.__reduce_ex__(self, *args) > > > > We should probably do that automatically for user-defined instances which > should be easy to do if this works for you. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Serge > *Sent:* Monday, October 06, 2008 7:36 PM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Serializing IronPython classes > > > > Thanks for the heads up, however trying to use cPickle, I still get the > error saying that the child class is not marked as serializable..? > > On 10/7/08, *Dino Viehland* wrote: > > I would strongly encourage you to use cPickle or pickle instead of .NET > serialization. In 2.0 all .NET serializable types can also be pickled ? > they define __reduce_ex__ which handles this. > > > > First off we should be setting the serializable bit on subclasses that are > serializable ? that's just a bug that we're not doing that. But once we've > done that the problem w/ .NET serialization is that ultimately we need a > static method or type that we can point at that does the deserialization. > For a user defined type in Python we will need to be able to deserialize the > type, the module the type lives in, and presumably even the ScriptRuntime > which holds the module. Pickle handles this by serializing the module & > type name but w/o a ScriptRuntime we couldn't even get at that. We might > have been able to require a ScriptRuntime to be smuggled in the > StreamingContext but it's not clear that it would work well. > > > > So if you really want .NET serialization we can fix the bug ? but you'll > need to implement ISerializable and figure out some way to deal getting the > class, module, and runtime information saved/restored yourself. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Serge > *Sent:* Sunday, October 05, 2008 9:24 PM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Serializing IronPython classes > > > > I've run into problems with serialization. I have a serializable class > defined in C# which gets extended from IP, however when I try to serialize a > collection of both parent and child instances, I get an exception saying > that the IP generated class is not marked as serializable. > > With the lack of attributes, I am guessing I must do something else to > enable serialization? > > Regards, Serge. > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed Oct 8 17:09:01 2008 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 8 Oct 2008 08:09:01 -0700 Subject: [IronPython] Serializing IronPython classes In-Reply-To: <18c139230810080605g17584ec6j6cedc0fa276b26ee@mail.gmail.com> References: <18c139230810052123h954b8b6i60f76278e8dcb18e@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B34B@NA-EXMSG-C102.redmond.corp.microsoft.com> <18c139230810061936q22a04d27xa6a5c116b8415c73@mail.gmail.com> <350E7D38B6D819428718949920EC2355478913B7C8@NA-EXMSG-C102.redmond.corp.microsoft.com> <18c139230810062115p6cbf9e3cq322ee7c857427076@mail.gmail.com> <350E7D38B6D819428718949920EC2355478926AA53@NA-EXMSG-C102.redmond.corp.microsoft.com> <18c139230810080605g17584ec6j6cedc0fa276b26ee@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355478926AEFE@NA-EXMSG-C102.redmond.corp.microsoft.com> I would suggest not using inheritance if you can. You can just hold onto the serializable object and delegate any work you need to be done to it. You'll be able to pickle the object graph that contains the Python object holding onto the non-inherited serializable object. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Serge Sent: Wednesday, October 08, 2008 6:06 AM To: Discussion of IronPython Subject: Re: [IronPython] Serializing IronPython classes Fair enough, thanks. Any suggestions on how to work around this in the meantime? On 10/8/08, Dino Viehland > wrote: Ok, upon looking into this some more, I'm sad to say it looks like this won't work right now :(. We need to figure out a way to run the serialization for just the base class and how to do that isn't entirely obvious - so it probably won't make 2.0. I've opened a bug to track the issue though: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=18823 Feel free to vote on it so we'll fix it sooner. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Serge Sent: Monday, October 06, 2008 9:15 PM To: Discussion of IronPython Subject: Re: [IronPython] Serializing IronPython classes Okay now this is getting interesting. I assumed that the warning was about the child class, but I'm not sure. A bit of info: The parent C# class is called Object. I did the override on on __reduce_ex__ as you suggested but trying to pickle still produced the same error: Type 'IronPython.NewTypes.Engine.Object_1$2' in Assembly 'Snippets.scripting, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' is not marked as serializable. For curiosity, I called __reduce_ex__ on a child instance and got the following error: expected Vector2, got Object_1$2 There are several Microsoft.Xna.Framework.Vector2 members and it looks like they're being replaced by this Object_1$2 which I assumed at first to be the child class because of its name. __reduce_ex__ on the parent instances works fine. I'm out of my depth here so I can't give more meaningful information. On 10/7/08, Dino Viehland > wrote: Ahh, that sounds like a bad bug, but I think I know what's causing it - we're hitting the new.NET serialization support because __reduce_ex__ is now defined for you :) Can you add an override that dispatches __reduce_ex__ to the object version, eg: def __reduce_ex__(self, *args): return object.__reduce_ex__(self, *args) We should probably do that automatically for user-defined instances which should be easy to do if this works for you. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Serge Sent: Monday, October 06, 2008 7:36 PM To: Discussion of IronPython Subject: Re: [IronPython] Serializing IronPython classes Thanks for the heads up, however trying to use cPickle, I still get the error saying that the child class is not marked as serializable..? On 10/7/08, Dino Viehland > wrote: I would strongly encourage you to use cPickle or pickle instead of .NET serialization. In 2.0 all .NET serializable types can also be pickled - they define __reduce_ex__ which handles this. First off we should be setting the serializable bit on subclasses that are serializable - that's just a bug that we're not doing that. But once we've done that the problem w/ .NET serialization is that ultimately we need a static method or type that we can point at that does the deserialization. For a user defined type in Python we will need to be able to deserialize the type, the module the type lives in, and presumably even the ScriptRuntime which holds the module. Pickle handles this by serializing the module & type name but w/o a ScriptRuntime we couldn't even get at that. We might have been able to require a ScriptRuntime to be smuggled in the StreamingContext but it's not clear that it would work well. So if you really want .NET serialization we can fix the bug - but you'll need to implement ISerializable and figure out some way to deal getting the class, module, and runtime information saved/restored yourself. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Serge Sent: Sunday, October 05, 2008 9:24 PM To: users at lists.ironpython.com Subject: [IronPython] Serializing IronPython classes I've run into problems with serialization. I have a serializable class defined in C# which gets extended from IP, however when I try to serialize a collection of both parent and child instances, I get an exception saying that the IP generated class is not marked as serializable. With the lack of attributes, I am guessing I must do something else to enable serialization? Regards, Serge. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Wed Oct 8 18:14:37 2008 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 8 Oct 2008 09:14:37 -0700 Subject: [IronPython] Problem Importing WinForms IPY2.0 B5 In-Reply-To: <20253b0c0810080503s2461e960w5213f34c91d46105@mail.gmail.com> References: <20253b0c0810072334m5f44aee3s54cb0171f1065a93@mail.gmail.com> <20253b0c0810080503s2461e960w5213f34c91d46105@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355478926AF8D@NA-EXMSG-C102.redmond.corp.microsoft.com> Thanks for the bug report. I've opened bug #18849 to track the issue - http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=18849 The fix is actually trivial so I expect it to be in the RC - we're just pass the wrong bools values (they should be flipped) to the ReflectedEvent ctor in PythonTypeOps.GetReflectedEvent. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Davy Mitchell Sent: Wednesday, October 08, 2008 5:03 AM To: Discussion of IronPython Subject: Re: [IronPython] Problem Importing WinForms IPY2.0 B5 Same code on IP 1.1.2 outputs: 699 696 Cheers, Davy On Wed, Oct 8, 2008 at 7:34 AM, Davy Mitchell > wrote: Hi All, Basic Repro is... ---------form.py------- import clr clr.AddReference('System.Windows.Forms') from System.Windows.Forms import * print len(dir(Form)) ---------test.py-------- from forms import * print len(dir(Form)) Output: 538 443 My real world case is a subclass of Form is in another module. The module that uses it tries to do mainform.KeyDown += self.DoSomething and fails as KeyDown has vanished. Yet if you copy and paset the subclass Form code into the same file it works! Forgive me if I am missing something obvious in the import mechanism :-) Thanks, Davy Mitchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.eloff at gmail.com Wed Oct 8 22:41:39 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Wed, 8 Oct 2008 15:41:39 -0500 Subject: [IronPython] Using IronPython AST Message-ID: <4817b6fc0810081341v513d1745t1810c3de2165397d@mail.gmail.com> I'm looking at the ast stuff in IronPython.Compiler.Ast and seeing how difficult it would be to write a python 2.5 _ast (and 2.6 ast) wrapper over it. Jython actually supports this now, and I don't wish to see IronPython left behind in this area. It looks like I should be able to handle a read-only ast without much difficulty. The trouble comes with altering the ast. It seems from looking at the code that everything is marked readonly, the ast cannot be modified in place? This is not a blocker, it's possible to handle all modifications in the wrapper, and then generate a new ast at the end that can be evaluated. For example: node = UnaryOp() node.op = USub() node.operand = Num() node.operand.n = 5 1) How would you turn this into an ast? Something like this maybe? node = new UnaryExpression(PythonOperator.Negate, new ConstantExpression(5)) 2) I assume there is a mechanism for compiling and/or executing an ast, please could someone show how to use it (you can build off the script below) 3) Is there a mechanism for turning an ast back into source code? This would help me with debugging. Thanks, -Dan Thanks to Dino for showing how to get an ast: import clr clr.AddReference('IronPython') clr.AddReference('Microsoft.Scripting') clr.AddReference('Microsoft.Scripting.Core') from IronPython.Compiler import Parser from Microsoft.Scripting import ErrorSink from Microsoft.Scripting.Runtime import CompilerContext from Microsoft.Scripting.Hosting.Providers import HostingHelpers from IronPython.Hosting import Python py = Python.CreateEngine() # beta 5 and beyond src = HostingHelpers.GetSourceUnit(py.CreateScriptSourceFromString('print "hello"')) pylc = HostingHelpers.GetLanguageContext(py) p = Parser.CreateParser(CompilerContext(src, pylc.GetCompilerOptions(), ErrorSink.Default), pylc.Options) ast = p.ParseFile(True) From dinov at microsoft.com Wed Oct 8 23:26:19 2008 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 8 Oct 2008 14:26:19 -0700 Subject: [IronPython] Using IronPython AST In-Reply-To: <4817b6fc0810081341v513d1745t1810c3de2165397d@mail.gmail.com> References: <4817b6fc0810081341v513d1745t1810c3de2165397d@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355478926B255@NA-EXMSG-C102.redmond.corp.microsoft.com> You're right on #1 - for other nodes you could also look at how the parser creates them (or ask if there's something particularly tricky). For #2 there isn't a good way to do this right now. You could cheat and do it with private reflection for the time being. First you need to create a PythonAst object (no problem, it's public). That will hold onto the tree you created and lets you control some knobs on how the code gen will proceed. You just need to call PythonNameBinder.BindAst(ast, compilerContext) (which is internal so reflection use #1) and then ast.TransformToAst (also internal, reflection use #2) which will return you a DLR LambdaExpression. From there you could go to the DLR and ask them to compile the lambda (Expression.Compile) or you could produce a ScriptCode object for it which you can run. The way we produce a ScriptCode once we have the lambda is: if ((pythonOptions.Module & ModuleOptions.Optimized) != 0) { return new OptimizedScriptCode(lambda, sourceUnit); } else { // TODO: fix generated DLR ASTs lambda = new GlobalLookupRewriter().RewriteLambda(lambda); return new ScriptCode(lambda, sourceUnit); } And you can basically do the same thing. The 1st path will leak memory if you're doing it repeatedly so you probably want the re-write & normal ScriptCode. We could probably do a little refactoring to expose this functionality onto PythonAst so that you can just new one of those up and get a ScriptCode back but it seems too much like a feature for it to make 2.0 at this point. On #3 unfortunately I didn't get our CodeDom code generator into 2.0 in time so it'll wait for the next release - mainly because I didn't have a chance to port the v1.0 tests forward. But it's pretty easy to grab it from the v1.1 sources and update it as our AST hasn't changed very much. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff Sent: Wednesday, October 08, 2008 1:42 PM To: Discussion of IronPython Subject: [IronPython] Using IronPython AST I'm looking at the ast stuff in IronPython.Compiler.Ast and seeing how difficult it would be to write a python 2.5 _ast (and 2.6 ast) wrapper over it. Jython actually supports this now, and I don't wish to see IronPython left behind in this area. It looks like I should be able to handle a read-only ast without much difficulty. The trouble comes with altering the ast. It seems from looking at the code that everything is marked readonly, the ast cannot be modified in place? This is not a blocker, it's possible to handle all modifications in the wrapper, and then generate a new ast at the end that can be evaluated. For example: node = UnaryOp() node.op = USub() node.operand = Num() node.operand.n = 5 1) How would you turn this into an ast? Something like this maybe? node = new UnaryExpression(PythonOperator.Negate, new ConstantExpression(5)) 2) I assume there is a mechanism for compiling and/or executing an ast, please could someone show how to use it (you can build off the script below) 3) Is there a mechanism for turning an ast back into source code? This would help me with debugging. Thanks, -Dan Thanks to Dino for showing how to get an ast: import clr clr.AddReference('IronPython') clr.AddReference('Microsoft.Scripting') clr.AddReference('Microsoft.Scripting.Core') from IronPython.Compiler import Parser from Microsoft.Scripting import ErrorSink from Microsoft.Scripting.Runtime import CompilerContext from Microsoft.Scripting.Hosting.Providers import HostingHelpers from IronPython.Hosting import Python py = Python.CreateEngine() # beta 5 and beyond src = HostingHelpers.GetSourceUnit(py.CreateScriptSourceFromString('print "hello"')) pylc = HostingHelpers.GetLanguageContext(py) p = Parser.CreateParser(CompilerContext(src, pylc.GetCompilerOptions(), ErrorSink.Default), pylc.Options) ast = p.ParseFile(True) _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dan.eloff at gmail.com Wed Oct 8 23:53:52 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Wed, 8 Oct 2008 16:53:52 -0500 Subject: [IronPython] Using IronPython AST In-Reply-To: <350E7D38B6D819428718949920EC2355478926B255@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <4817b6fc0810081341v513d1745t1810c3de2165397d@mail.gmail.com> <350E7D38B6D819428718949920EC2355478926B255@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <4817b6fc0810081453p48d5f1a0i3477bbed1ac13299@mail.gmail.com> #1 - Great, I can manage that. #2 - This is promising. Because I want this to work in silverlight as well, I'll have to patch IronPython to give a public interface, but that looks remarkably simple from what you've told me. That's fine for enabling me to continue forward, but not for sharing my work on this later. Any chance we can get a public interface? Ideally if I pull this off, my work should find its way into IronPython, but I understand that will have to wait until the legal hurdles with accepting community contributions have been cleared. #3 - Sounds good, it's C# so fortuantly the compiler will flag most of the breakages for me. Thanks, -Dan On Wed, Oct 8, 2008 at 4:26 PM, Dino Viehland wrote: > You're right on #1 - for other nodes you could also look at how the parser creates them (or ask if there's something particularly tricky). > > For #2 there isn't a good way to do this right now. You could cheat and do it with private reflection for the time being. First you need to create a PythonAst object (no problem, it's public). That will hold onto the tree you created and lets you control some knobs on how the code gen will proceed. You just need to call PythonNameBinder.BindAst(ast, compilerContext) (which is internal so reflection use #1) and then ast.TransformToAst (also internal, reflection use #2) which will return you a DLR LambdaExpression. From there you could go to the DLR and ask them to compile the lambda (Expression.Compile) or you could produce a ScriptCode object for it which you can run. The way we produce a ScriptCode once we have the lambda is: > > if ((pythonOptions.Module & ModuleOptions.Optimized) != 0) { > return new OptimizedScriptCode(lambda, sourceUnit); > } else { > // TODO: fix generated DLR ASTs > lambda = new GlobalLookupRewriter().RewriteLambda(lambda); > return new ScriptCode(lambda, sourceUnit); > } > > And you can basically do the same thing. The 1st path will leak memory if you're doing it repeatedly so you probably want the re-write & normal ScriptCode. > > We could probably do a little refactoring to expose this functionality onto PythonAst so that you can just new one of those up and get a ScriptCode back but it seems too much like a feature for it to make 2.0 at this point. > > On #3 unfortunately I didn't get our CodeDom code generator into 2.0 in time so it'll wait for the next release - mainly because I didn't have a chance to port the v1.0 tests forward. But it's pretty easy to grab it from the v1.1 sources and update it as our AST hasn't changed very much. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff > Sent: Wednesday, October 08, 2008 1:42 PM > To: Discussion of IronPython > Subject: [IronPython] Using IronPython AST > > I'm looking at the ast stuff in IronPython.Compiler.Ast and seeing how > difficult it would be to write a python 2.5 _ast (and 2.6 ast) wrapper > over it. > > Jython actually supports this now, and I don't wish to see IronPython > left behind in this area. > > It looks like I should be able to handle a read-only ast without much > difficulty. The trouble comes with altering the ast. It seems from > looking at the code that everything is marked readonly, the ast cannot > be modified in place? > > This is not a blocker, it's possible to handle all modifications in > the wrapper, and then generate a new ast at the end that can be > evaluated. > > For example: > > node = UnaryOp() > node.op = USub() > node.operand = Num() > node.operand.n = 5 > > 1) How would you turn this into an ast? Something like this maybe? > > node = new UnaryExpression(PythonOperator.Negate, new ConstantExpression(5)) > > 2) I assume there is a mechanism for compiling and/or executing an > ast, please could someone show how to use it (you can build off the > script below) > > 3) Is there a mechanism for turning an ast back into source code? This > would help me with debugging. > > Thanks, > -Dan > > Thanks to Dino for showing how to get an ast: > > import clr > clr.AddReference('IronPython') > clr.AddReference('Microsoft.Scripting') > clr.AddReference('Microsoft.Scripting.Core') > from IronPython.Compiler import Parser > > from Microsoft.Scripting import ErrorSink > from Microsoft.Scripting.Runtime import CompilerContext > from Microsoft.Scripting.Hosting.Providers import HostingHelpers > from IronPython.Hosting import Python > py = Python.CreateEngine() # beta 5 and beyond > > src = HostingHelpers.GetSourceUnit(py.CreateScriptSourceFromString('print > "hello"')) > pylc = HostingHelpers.GetLanguageContext(py) > > > p = Parser.CreateParser(CompilerContext(src, > pylc.GetCompilerOptions(), ErrorSink.Default), pylc.Options) > ast = p.ParseFile(True) > _______________________________________________ > 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 Marty.Nelson at symyx.com Thu Oct 9 00:09:40 2008 From: Marty.Nelson at symyx.com (Marty Nelson) Date: Wed, 8 Oct 2008 15:09:40 -0700 Subject: [IronPython] Questions and Best Practices for Script Runtime and Script Engine Message-ID: <515335F32AA04440B3DE6FEA1993E9AD039BCDE2@srv-be-101.Symyx-IC.symyx.com> I have a ScriptingService static class that reuses the same ScriptRuntime instance. Is there any reason not to do this? What would be the boundary conditions at which I would want to use a different ScriptRuntime? Does the call to scriptRuntime.GetEngine("py") always return the same engine instance? Again, why or why not reuse the same instance? Lastly, I was somewhat confused by the change from ScriptRuntime.Create() to Python.CreateRuntime(). Are the runtimes, and more importantly ScriptScope's, reusable with other DLR languages? I was expecting to be able to do something like the following: ScriptScope scope = scriptRuntime.CreateScope(); ScriptEngine pythonEngine = scriptRuntime.GetEngine("py"); pythonEngine.CreateScriptSourceFromString(pythonScript, SourceCodeKind.Statements).Execute(scope); ScriptEngine rubyEngine = scriptRuntime.GetEngine("ruby"); pythonEngine.CreateScriptSourceFromString(rubyScript, SourceCodeKind.Statements).Execute(scope); Thanks, - Marty Nelson ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Oct 9 00:09:55 2008 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 8 Oct 2008 15:09:55 -0700 Subject: [IronPython] Using IronPython AST In-Reply-To: <4817b6fc0810081453p48d5f1a0i3477bbed1ac13299@mail.gmail.com> References: <4817b6fc0810081341v513d1745t1810c3de2165397d@mail.gmail.com> <350E7D38B6D819428718949920EC2355478926B255@NA-EXMSG-C102.redmond.corp.microsoft.com> <4817b6fc0810081453p48d5f1a0i3477bbed1ac13299@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC2355478926B2B4@NA-EXMSG-C102.redmond.corp.microsoft.com> I definitely think we can add a nice public interface in the near future - probably even in 2.0.1. I just don't want to rush it in for 2.0 final and especially before you have a chance to give it a shot :) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff Sent: Wednesday, October 08, 2008 2:54 PM To: Discussion of IronPython Subject: Re: [IronPython] Using IronPython AST #1 - Great, I can manage that. #2 - This is promising. Because I want this to work in silverlight as well, I'll have to patch IronPython to give a public interface, but that looks remarkably simple from what you've told me. That's fine for enabling me to continue forward, but not for sharing my work on this later. Any chance we can get a public interface? Ideally if I pull this off, my work should find its way into IronPython, but I understand that will have to wait until the legal hurdles with accepting community contributions have been cleared. #3 - Sounds good, it's C# so fortuantly the compiler will flag most of the breakages for me. Thanks, -Dan On Wed, Oct 8, 2008 at 4:26 PM, Dino Viehland wrote: > You're right on #1 - for other nodes you could also look at how the parser creates them (or ask if there's something particularly tricky). > > For #2 there isn't a good way to do this right now. You could cheat and do it with private reflection for the time being. First you need to create a PythonAst object (no problem, it's public). That will hold onto the tree you created and lets you control some knobs on how the code gen will proceed. You just need to call PythonNameBinder.BindAst(ast, compilerContext) (which is internal so reflection use #1) and then ast.TransformToAst (also internal, reflection use #2) which will return you a DLR LambdaExpression. From there you could go to the DLR and ask them to compile the lambda (Expression.Compile) or you could produce a ScriptCode object for it which you can run. The way we produce a ScriptCode once we have the lambda is: > > if ((pythonOptions.Module & ModuleOptions.Optimized) != 0) { > return new OptimizedScriptCode(lambda, sourceUnit); > } else { > // TODO: fix generated DLR ASTs > lambda = new GlobalLookupRewriter().RewriteLambda(lambda); > return new ScriptCode(lambda, sourceUnit); > } > > And you can basically do the same thing. The 1st path will leak memory if you're doing it repeatedly so you probably want the re-write & normal ScriptCode. > > We could probably do a little refactoring to expose this functionality onto PythonAst so that you can just new one of those up and get a ScriptCode back but it seems too much like a feature for it to make 2.0 at this point. > > On #3 unfortunately I didn't get our CodeDom code generator into 2.0 in time so it'll wait for the next release - mainly because I didn't have a chance to port the v1.0 tests forward. But it's pretty easy to grab it from the v1.1 sources and update it as our AST hasn't changed very much. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff > Sent: Wednesday, October 08, 2008 1:42 PM > To: Discussion of IronPython > Subject: [IronPython] Using IronPython AST > > I'm looking at the ast stuff in IronPython.Compiler.Ast and seeing how > difficult it would be to write a python 2.5 _ast (and 2.6 ast) wrapper > over it. > > Jython actually supports this now, and I don't wish to see IronPython > left behind in this area. > > It looks like I should be able to handle a read-only ast without much > difficulty. The trouble comes with altering the ast. It seems from > looking at the code that everything is marked readonly, the ast cannot > be modified in place? > > This is not a blocker, it's possible to handle all modifications in > the wrapper, and then generate a new ast at the end that can be > evaluated. > > For example: > > node = UnaryOp() > node.op = USub() > node.operand = Num() > node.operand.n = 5 > > 1) How would you turn this into an ast? Something like this maybe? > > node = new UnaryExpression(PythonOperator.Negate, new ConstantExpression(5)) > > 2) I assume there is a mechanism for compiling and/or executing an > ast, please could someone show how to use it (you can build off the > script below) > > 3) Is there a mechanism for turning an ast back into source code? This > would help me with debugging. > > Thanks, > -Dan > > Thanks to Dino for showing how to get an ast: > > import clr > clr.AddReference('IronPython') > clr.AddReference('Microsoft.Scripting') > clr.AddReference('Microsoft.Scripting.Core') > from IronPython.Compiler import Parser > > from Microsoft.Scripting import ErrorSink > from Microsoft.Scripting.Runtime import CompilerContext > from Microsoft.Scripting.Hosting.Providers import HostingHelpers > from IronPython.Hosting import Python > py = Python.CreateEngine() # beta 5 and beyond > > src = HostingHelpers.GetSourceUnit(py.CreateScriptSourceFromString('print > "hello"')) > pylc = HostingHelpers.GetLanguageContext(py) > > > p = Parser.CreateParser(CompilerContext(src, > pylc.GetCompilerOptions(), ErrorSink.Default), pylc.Options) > ast = p.ParseFile(True) > _______________________________________________ > 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 Marty.Nelson at symyx.com Thu Oct 9 00:16:41 2008 From: Marty.Nelson at symyx.com (Marty Nelson) Date: Wed, 8 Oct 2008 15:16:41 -0700 Subject: [IronPython] Iron Python release dates Message-ID: <515335F32AA04440B3DE6FEA1993E9AD039BCDEB@srv-be-101.Symyx-IC.symyx.com> We have a release scheduled for mid-December. If IP 2.0 is not officially released, can we go live with an RC? Thanks, Marty Nelson Symyx Technologies, Inc. ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Thu Oct 9 00:21:01 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 8 Oct 2008 15:21:01 -0700 Subject: [IronPython] Iron Python release dates In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD039BCDEB@srv-be-101.Symyx-IC.symyx.com> References: <515335F32AA04440B3DE6FEA1993E9AD039BCDEB@srv-be-101.Symyx-IC.symyx.com> Message-ID: Given the open source nature of the project, you can go live with whatever you want! The flip side of that is that support is pretty much limited to what you get on this list. Though we'd like to think that the free support you get from us is at least as good as what you pay for from PSS. :) On Wed, Oct 8, 2008 at 3:16 PM, Marty Nelson wrote: > We have a release scheduled for mid-December. If IP 2.0 is not > officially released, can we go live with an RC? > > > > Thanks, > > > > *Marty Nelson* > > *Symyx Technologies, Inc.* > ======= > Notice: This e-mail message, together with any attachments, contains > information of Symyx Technologies, Inc. or any of its affiliates or > subsidiaries that may be confidential, proprietary, copyrighted, > privileged and/or protected work product, and is meant solely for > the intended recipient. If you are not the intended recipient, and > have received this message in error, please contact the sender > immediately, permanently delete the original and any copies of this > email and any attachments thereto. > > _______________________________________________ > 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 Marty.Nelson at symyx.com Thu Oct 9 00:55:43 2008 From: Marty.Nelson at symyx.com (Marty Nelson) Date: Wed, 8 Oct 2008 15:55:43 -0700 Subject: [IronPython] Iron Python release dates In-Reply-To: References: <515335F32AA04440B3DE6FEA1993E9AD039BCDEB@srv-be-101.Symyx-IC.symyx.com> Message-ID: <515335F32AA04440B3DE6FEA1993E9AD039BCE15@srv-be-101.Symyx-IC.symyx.com> Ok. What's the latest thinking on the schedule at this point? Will we at least be to RC? ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Wednesday, October 08, 2008 3:21 PM To: Discussion of IronPython Subject: Re: [IronPython] Iron Python release dates Given the open source nature of the project, you can go live with whatever you want! The flip side of that is that support is pretty much limited to what you get on this list. Though we'd like to think that the free support you get from us is at least as good as what you pay for from PSS. :) On Wed, Oct 8, 2008 at 3:16 PM, Marty Nelson wrote: We have a release scheduled for mid-December. If IP 2.0 is not officially released, can we go live with an RC? Thanks, Marty Nelson Symyx Technologies, Inc. ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Oct 9 00:59:43 2008 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 8 Oct 2008 15:59:43 -0700 Subject: [IronPython] Questions and Best Practices for Script Runtime and Script Engine In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD039BCDE2@srv-be-101.Symyx-IC.symyx.com> References: <515335F32AA04440B3DE6FEA1993E9AD039BCDE2@srv-be-101.Symyx-IC.symyx.com> Message-ID: <350E7D38B6D819428718949920EC2355478926B311@NA-EXMSG-C102.redmond.corp.microsoft.com> Each ScriptRuntime is isolated from each other. So the reasons to use multiple ones would come down to wanting to set different global options, have scripts belonging to different users running, have scripts running on multiple threads which are isolated, etc... It can also be useful to run a ScriptRuntime in another domain so you can deterministically unload all of the code - that might be useful for a plug-in model where you want to have the capability to unload all of the plugins. Each ScriptRuntime will only have 1 instance of each language - so scriptRuntime.GetEngine("py") will always return the same instance. The change from ScriptRuntime.Create to Python.CreateRuntime() is all about where the hosting APIs are heading long term. Eventually they'll become a part of the .NET framework and we currently have no plans to ship IronPython w/ the framework - we tend to move faster than they do :). That implies that the DLR hosting APIs shouldn't have knowledge of Python either. We looked at a couple of ways of solving this and we were interested in making sure that we had a good experience for both the single-language case as well as the multi-language case. For the single language case we came up with Python.CreateRuntime where Python can return you a ScriptRuntime that is pre-configured to include just the IronPython language configured - IronRuby has a similar method as well. For the multi-language case we added a configuration mechanism built off of the standard .NET config file format. You can do an easy one-liner there by calling ScriptRuntime.CreateFromConfiguration() which will read .NET config (app config, web.config, etc...). That way you can plug in multiple languages and users of your app can add/remove/update languages as they so choose. The configuration file format looks like:

So coming back to the question about ScriptScopes you absolutely can re-use them between languages. Each language will have its own mechanism for exposing the variables in the scope (for Python they're globals, in Ruby Tomas tells me they're ultimately exposed via method_missing so you can just refer to them by name or self.name). Note though a ScriptScope can be bound to a language which is then used for fetching variables, doing conversions, etc... From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Wednesday, October 08, 2008 3:10 PM To: users at lists.ironpython.com Subject: [IronPython] Questions and Best Practices for Script Runtime and Script Engine I have a ScriptingService static class that reuses the same ScriptRuntime instance. Is there any reason not to do this? What would be the boundary conditions at which I would want to use a different ScriptRuntime? Does the call to scriptRuntime.GetEngine("py") always return the same engine instance? Again, why or why not reuse the same instance? Lastly, I was somewhat confused by the change from ScriptRuntime.Create() to Python.CreateRuntime(). Are the runtimes, and more importantly ScriptScope's, reusable with other DLR languages? I was expecting to be able to do something like the following: ScriptScope scope = scriptRuntime.CreateScope(); ScriptEngine pythonEngine = scriptRuntime.GetEngine("py"); pythonEngine.CreateScriptSourceFromString(pythonScript, SourceCodeKind.Statements).Execute(scope); ScriptEngine rubyEngine = scriptRuntime.GetEngine("ruby"); pythonEngine.CreateScriptSourceFromString(rubyScript, SourceCodeKind.Statements).Execute(scope); Thanks, - Marty Nelson ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marty.Nelson at symyx.com Thu Oct 9 01:04:58 2008 From: Marty.Nelson at symyx.com (Marty Nelson) Date: Wed, 8 Oct 2008 16:04:58 -0700 Subject: [IronPython] Iron Python release dates In-Reply-To: References: <515335F32AA04440B3DE6FEA1993E9AD039BCDEB@srv-be-101.Symyx-IC.symyx.com> Message-ID: <515335F32AA04440B3DE6FEA1993E9AD039BCE1E@srv-be-101.Symyx-IC.symyx.com> And yes support is great. Although, perhaps more importantly, for how we use it, it just seems to "work", so there isn't much support we have needed :-) ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Wednesday, October 08, 2008 3:21 PM To: Discussion of IronPython Subject: Re: [IronPython] Iron Python release dates Given the open source nature of the project, you can go live with whatever you want! The flip side of that is that support is pretty much limited to what you get on this list. Though we'd like to think that the free support you get from us is at least as good as what you pay for from PSS. :) On Wed, Oct 8, 2008 at 3:16 PM, Marty Nelson wrote: We have a release scheduled for mid-December. If IP 2.0 is not officially released, can we go live with an RC? Thanks, Marty Nelson Symyx Technologies, Inc. ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Thu Oct 9 01:27:30 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Wed, 8 Oct 2008 16:27:30 -0700 Subject: [IronPython] Iron Python release dates In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD039BCE15@srv-be-101.Symyx-IC.symyx.com> References: <515335F32AA04440B3DE6FEA1993E9AD039BCDEB@srv-be-101.Symyx-IC.symyx.com> <515335F32AA04440B3DE6FEA1993E9AD039BCE15@srv-be-101.Symyx-IC.symyx.com> Message-ID: We expect RC1 in about 1-2 weeks and the final release by the end of November. Exact dates are -- as always -- subject to change. On Wed, Oct 8, 2008 at 3:55 PM, Marty Nelson wrote: > Ok. What's the latest thinking on the schedule at this point? Will we > at least be to RC? > > > ------------------------------ > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Curt Hagenlocher > *Sent:* Wednesday, October 08, 2008 3:21 PM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Iron Python release dates > > > > Given the open source nature of the project, you can go live with whatever > you want! The flip side of that is that support is pretty much limited to > what you get on this list. Though we'd like to think that the free support > you get from us is at least as good as what you pay for from PSS. :) > > > > On Wed, Oct 8, 2008 at 3:16 PM, Marty Nelson > wrote: > > We have a release scheduled for mid-December. If IP 2.0 is not officially > released, can we go live with an RC? > > > > Thanks, > > > > *Marty Nelson* > > *Symyx Technologies, Inc.* > > ======= > Notice: This e-mail message, together with any attachments, contains > information of Symyx Technologies, Inc. or any of its affiliates or > subsidiaries that may be confidential, proprietary, copyrighted, > privileged and/or protected work product, and is meant solely for > the intended recipient. If you are not the intended recipient, and > have received this message in error, please contact the sender > immediately, permanently delete the original and any copies of this > email and any attachments thereto. > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marty.Nelson at symyx.com Thu Oct 9 03:39:57 2008 From: Marty.Nelson at symyx.com (Marty Nelson) Date: Wed, 8 Oct 2008 18:39:57 -0700 Subject: [IronPython] Questions and Best Practices for Script Runtimeand Script Engine In-Reply-To: <350E7D38B6D819428718949920EC2355478926B311@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <515335F32AA04440B3DE6FEA1993E9AD039BCDE2@srv-be-101.Symyx-IC.symyx.com> <350E7D38B6D819428718949920EC2355478926B311@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <515335F32AA04440B3DE6FEA1993E9AD039BCE60@srv-be-101.Symyx-IC.symyx.com> Thanks, this is very helpful and close to what I expected. We use scripting as an event-based customization mechanism, so the scripts typically need to be in the same app-domain so they can get their grubby little hands all over the objects being manipulated. Is there any code based mechanisms to add the configurations? In a deployed enterprise environment, updating config files is not something our customers are excited about. We can deal with dynamic deployed types and assemblies via the server portion of our product, if there was something exposed we can manipulate against the API, that would be better. ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, October 08, 2008 4:00 PM To: Discussion of IronPython Subject: Re: [IronPython] Questions and Best Practices for Script Runtimeand Script Engine Each ScriptRuntime is isolated from each other. So the reasons to use multiple ones would come down to wanting to set different global options, have scripts belonging to different users running, have scripts running on multiple threads which are isolated, etc... It can also be useful to run a ScriptRuntime in another domain so you can deterministically unload all of the code - that might be useful for a plug-in model where you want to have the capability to unload all of the plugins. Each ScriptRuntime will only have 1 instance of each language - so scriptRuntime.GetEngine("py") will always return the same instance. The change from ScriptRuntime.Create to Python.CreateRuntime() is all about where the hosting APIs are heading long term. Eventually they'll become a part of the .NET framework and we currently have no plans to ship IronPython w/ the framework - we tend to move faster than they do :-). That implies that the DLR hosting APIs shouldn't have knowledge of Python either. We looked at a couple of ways of solving this and we were interested in making sure that we had a good experience for both the single-language case as well as the multi-language case. For the single language case we came up with Python.CreateRuntime where Python can return you a ScriptRuntime that is pre-configured to include just the IronPython language configured - IronRuby has a similar method as well. For the multi-language case we added a configuration mechanism built off of the standard .NET config file format. You can do an easy one-liner there by calling ScriptRuntime.CreateFromConfiguration() which will read .NET config (app config, web.config, etc...). That way you can plug in multiple languages and users of your app can add/remove/update languages as they so choose. The configuration file format looks like:
So coming back to the question about ScriptScopes you absolutely can re-use them between languages. Each language will have its own mechanism for exposing the variables in the scope (for Python they're globals, in Ruby Tomas tells me they're ultimately exposed via method_missing so you can just refer to them by name or self.name). Note though a ScriptScope can be bound to a language which is then used for fetching variables, doing conversions, etc... From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Wednesday, October 08, 2008 3:10 PM To: users at lists.ironpython.com Subject: [IronPython] Questions and Best Practices for Script Runtime and Script Engine I have a ScriptingService static class that reuses the same ScriptRuntime instance. Is there any reason not to do this? What would be the boundary conditions at which I would want to use a different ScriptRuntime? Does the call to scriptRuntime.GetEngine("py") always return the same engine instance? Again, why or why not reuse the same instance? Lastly, I was somewhat confused by the change from ScriptRuntime.Create() to Python.CreateRuntime(). Are the runtimes, and more importantly ScriptScope's, reusable with other DLR languages? I was expecting to be able to do something like the following: ScriptScope scope = scriptRuntime.CreateScope(); ScriptEngine pythonEngine = scriptRuntime.GetEngine("py"); pythonEngine.CreateScriptSourceFromString(pythonScript, SourceCodeKind.Statements).Execute(scope); ScriptEngine rubyEngine = scriptRuntime.GetEngine("ruby"); pythonEngine.CreateScriptSourceFromString(rubyScript, SourceCodeKind.Statements).Execute(scope); Thanks, - Marty Nelson ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Oct 9 03:45:00 2008 From: dinov at microsoft.com (Dino Viehland) Date: Wed, 8 Oct 2008 18:45:00 -0700 Subject: [IronPython] Questions and Best Practices for Script Runtimeand Script Engine In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD039BCE60@srv-be-101.Symyx-IC.symyx.com> References: <515335F32AA04440B3DE6FEA1993E9AD039BCDE2@srv-be-101.Symyx-IC.symyx.com> <350E7D38B6D819428718949920EC2355478926B311@NA-EXMSG-C102.redmond.corp.microsoft.com> <515335F32AA04440B3DE6FEA1993E9AD039BCE60@srv-be-101.Symyx-IC.symyx.com> Message-ID: <350E7D38B6D819428718949920EC2355478926B3C2@NA-EXMSG-C102.redmond.corp.microsoft.com> Absolutely - you can create a ScriptRuntimeSetup and pass that to the ScriptRuntime constructor. That's basically: ScriptRuntimeSetup setup = new ScriptRuntimeSetup(); Setup.LanguageSetups.Add(new LanguageSetup(assembly_qualified_name, displayName, languageNames, fileExtensions); If you want a more detailed example you can look at the Python class in IronPython which does this and a little more... Using that you can develop any alternate configuration mechanism that you'd like. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Wednesday, October 08, 2008 6:40 PM To: Discussion of IronPython Subject: Re: [IronPython] Questions and Best Practices for Script Runtimeand Script Engine Thanks, this is very helpful and close to what I expected. We use scripting as an event-based customization mechanism, so the scripts typically need to be in the same app-domain so they can get their grubby little hands all over the objects being manipulated. Is there any code based mechanisms to add the configurations? In a deployed enterprise environment, updating config files is not something our customers are excited about. We can deal with dynamic deployed types and assemblies via the server portion of our product, if there was something exposed we can manipulate against the API, that would be better. ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, October 08, 2008 4:00 PM To: Discussion of IronPython Subject: Re: [IronPython] Questions and Best Practices for Script Runtimeand Script Engine Each ScriptRuntime is isolated from each other. So the reasons to use multiple ones would come down to wanting to set different global options, have scripts belonging to different users running, have scripts running on multiple threads which are isolated, etc... It can also be useful to run a ScriptRuntime in another domain so you can deterministically unload all of the code - that might be useful for a plug-in model where you want to have the capability to unload all of the plugins. Each ScriptRuntime will only have 1 instance of each language - so scriptRuntime.GetEngine("py") will always return the same instance. The change from ScriptRuntime.Create to Python.CreateRuntime() is all about where the hosting APIs are heading long term. Eventually they'll become a part of the .NET framework and we currently have no plans to ship IronPython w/ the framework - we tend to move faster than they do :). That implies that the DLR hosting APIs shouldn't have knowledge of Python either. We looked at a couple of ways of solving this and we were interested in making sure that we had a good experience for both the single-language case as well as the multi-language case. For the single language case we came up with Python.CreateRuntime where Python can return you a ScriptRuntime that is pre-configured to include just the IronPython language configured - IronRuby has a similar method as well. For the multi-language case we added a configuration mechanism built off of the standard .NET config file format. You can do an easy one-liner there by calling ScriptRuntime.CreateFromConfiguration() which will read .NET config (app config, web.config, etc...). That way you can plug in multiple languages and users of your app can add/remove/update languages as they so choose. The configuration file format looks like:
So coming back to the question about ScriptScopes you absolutely can re-use them between languages. Each language will have its own mechanism for exposing the variables in the scope (for Python they're globals, in Ruby Tomas tells me they're ultimately exposed via method_missing so you can just refer to them by name or self.name). Note though a ScriptScope can be bound to a language which is then used for fetching variables, doing conversions, etc... From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Wednesday, October 08, 2008 3:10 PM To: users at lists.ironpython.com Subject: [IronPython] Questions and Best Practices for Script Runtime and Script Engine I have a ScriptingService static class that reuses the same ScriptRuntime instance. Is there any reason not to do this? What would be the boundary conditions at which I would want to use a different ScriptRuntime? Does the call to scriptRuntime.GetEngine("py") always return the same engine instance? Again, why or why not reuse the same instance? Lastly, I was somewhat confused by the change from ScriptRuntime.Create() to Python.CreateRuntime(). Are the runtimes, and more importantly ScriptScope's, reusable with other DLR languages? I was expecting to be able to do something like the following: ScriptScope scope = scriptRuntime.CreateScope(); ScriptEngine pythonEngine = scriptRuntime.GetEngine("py"); pythonEngine.CreateScriptSourceFromString(pythonScript, SourceCodeKind.Statements).Execute(scope); ScriptEngine rubyEngine = scriptRuntime.GetEngine("ruby"); pythonEngine.CreateScriptSourceFromString(rubyScript, SourceCodeKind.Statements).Execute(scope); Thanks, - Marty Nelson ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marty.Nelson at symyx.com Thu Oct 9 03:50:10 2008 From: Marty.Nelson at symyx.com (Marty Nelson) Date: Wed, 8 Oct 2008 18:50:10 -0700 Subject: [IronPython] Questions and Best Practices forScript Runtimeand Script Engine In-Reply-To: <350E7D38B6D819428718949920EC2355478926B3C2@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <515335F32AA04440B3DE6FEA1993E9AD039BCDE2@srv-be-101.Symyx-IC.symyx.com><350E7D38B6D819428718949920EC2355478926B311@NA-EXMSG-C102.redmond.corp.microsoft.com><515335F32AA04440B3DE6FEA1993E9AD039BCE60@srv-be-101.Symyx-IC.symyx.com> <350E7D38B6D819428718949920EC2355478926B3C2@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <515335F32AA04440B3DE6FEA1993E9AD039BCE61@srv-be-101.Symyx-IC.symyx.com> Perfect. Well done! ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, October 08, 2008 6:45 PM To: Discussion of IronPython Subject: Re: [IronPython] Questions and Best Practices forScript Runtimeand Script Engine Absolutely - you can create a ScriptRuntimeSetup and pass that to the ScriptRuntime constructor. That's basically: ScriptRuntimeSetup setup = new ScriptRuntimeSetup(); Setup.LanguageSetups.Add(new LanguageSetup(assembly_qualified_name, displayName, languageNames, fileExtensions); If you want a more detailed example you can look at the Python class in IronPython which does this and a little more... Using that you can develop any alternate configuration mechanism that you'd like. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Wednesday, October 08, 2008 6:40 PM To: Discussion of IronPython Subject: Re: [IronPython] Questions and Best Practices for Script Runtimeand Script Engine Thanks, this is very helpful and close to what I expected. We use scripting as an event-based customization mechanism, so the scripts typically need to be in the same app-domain so they can get their grubby little hands all over the objects being manipulated. Is there any code based mechanisms to add the configurations? In a deployed enterprise environment, updating config files is not something our customers are excited about. We can deal with dynamic deployed types and assemblies via the server portion of our product, if there was something exposed we can manipulate against the API, that would be better. ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Wednesday, October 08, 2008 4:00 PM To: Discussion of IronPython Subject: Re: [IronPython] Questions and Best Practices for Script Runtimeand Script Engine Each ScriptRuntime is isolated from each other. So the reasons to use multiple ones would come down to wanting to set different global options, have scripts belonging to different users running, have scripts running on multiple threads which are isolated, etc... It can also be useful to run a ScriptRuntime in another domain so you can deterministically unload all of the code - that might be useful for a plug-in model where you want to have the capability to unload all of the plugins. Each ScriptRuntime will only have 1 instance of each language - so scriptRuntime.GetEngine("py") will always return the same instance. The change from ScriptRuntime.Create to Python.CreateRuntime() is all about where the hosting APIs are heading long term. Eventually they'll become a part of the .NET framework and we currently have no plans to ship IronPython w/ the framework - we tend to move faster than they do :-). That implies that the DLR hosting APIs shouldn't have knowledge of Python either. We looked at a couple of ways of solving this and we were interested in making sure that we had a good experience for both the single-language case as well as the multi-language case. For the single language case we came up with Python.CreateRuntime where Python can return you a ScriptRuntime that is pre-configured to include just the IronPython language configured - IronRuby has a similar method as well. For the multi-language case we added a configuration mechanism built off of the standard .NET config file format. You can do an easy one-liner there by calling ScriptRuntime.CreateFromConfiguration() which will read .NET config (app config, web.config, etc...). That way you can plug in multiple languages and users of your app can add/remove/update languages as they so choose. The configuration file format looks like:
So coming back to the question about ScriptScopes you absolutely can re-use them between languages. Each language will have its own mechanism for exposing the variables in the scope (for Python they're globals, in Ruby Tomas tells me they're ultimately exposed via method_missing so you can just refer to them by name or self.name). Note though a ScriptScope can be bound to a language which is then used for fetching variables, doing conversions, etc... From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Wednesday, October 08, 2008 3:10 PM To: users at lists.ironpython.com Subject: [IronPython] Questions and Best Practices for Script Runtime and Script Engine I have a ScriptingService static class that reuses the same ScriptRuntime instance. Is there any reason not to do this? What would be the boundary conditions at which I would want to use a different ScriptRuntime? Does the call to scriptRuntime.GetEngine("py") always return the same engine instance? Again, why or why not reuse the same instance? Lastly, I was somewhat confused by the change from ScriptRuntime.Create() to Python.CreateRuntime(). Are the runtimes, and more importantly ScriptScope's, reusable with other DLR languages? I was expecting to be able to do something like the following: ScriptScope scope = scriptRuntime.CreateScope(); ScriptEngine pythonEngine = scriptRuntime.GetEngine("py"); pythonEngine.CreateScriptSourceFromString(pythonScript, SourceCodeKind.Statements).Execute(scope); ScriptEngine rubyEngine = scriptRuntime.GetEngine("ruby"); pythonEngine.CreateScriptSourceFromString(rubyScript, SourceCodeKind.Statements).Execute(scope); Thanks, - Marty Nelson ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Thu Oct 9 06:45:53 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Thu, 9 Oct 2008 13:45:53 +0900 Subject: [IronPython] Warning CS3006 Message-ID: <5b0248170810082145p41ae340dx83bf8a3f1dc82247@mail.gmail.com> Can you confirm that following two warnings are likely to be a Mono compiler bug? /home/tinuviel/svn/ironpython/Src/Microsoft.Scripting.Core/Actions/GetMemberAction.cs(44,43): warning CS3006: Overloaded method `Microsoft.Scripting.Actions.GetMemberAction.Bind(params Microsoft.Scripting.Actions.MetaObject[])' differing only in ref or out, or in array rank, is not CLS-compliant /home/tinuviel/svn/ironpython/Src/Microsoft.Scripting/Actions/ComboBinder.cs(42,36): warning CS3006: Overloaded method `Microsoft.Scripting.Actions.ComboBinder.Bind(params Microsoft.Scripting.Actions.MetaObject[])' differing only in ref or out, or in array rank, is not CLS-compliant /home/tinuviel/svn/ironpython/Src/Microsoft.Scripting.Core/Actions/MetaAction.cs(159,36): (Location of the symbol related to previous warning) Otherwise, I am very happy to report that entire IronPython codebase is warning-free on Mono now! -- Seo Sanghyeon From dinov at microsoft.com Fri Oct 10 19:38:19 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 10 Oct 2008 10:38:19 -0700 Subject: [IronPython] Warning CS3006 In-Reply-To: <5b0248170810082145p41ae340dx83bf8a3f1dc82247@mail.gmail.com> References: <5b0248170810082145p41ae340dx83bf8a3f1dc82247@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23554789335B89@NA-EXMSG-C102.redmond.corp.microsoft.com> It sure looks like it - are there more though? I'd expect one for each action kind. The methods differ in generic arity and the type of array they accept so at the very least the error string is wrong even if it is bad style to differ that way. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon Sent: Wednesday, October 08, 2008 9:46 PM To: Discussion of IronPython Subject: [IronPython] Warning CS3006 Can you confirm that following two warnings are likely to be a Mono compiler bug? /home/tinuviel/svn/ironpython/Src/Microsoft.Scripting.Core/Actions/GetMemberAction.cs(44,43): warning CS3006: Overloaded method `Microsoft.Scripting.Actions.GetMemberAction.Bind(params Microsoft.Scripting.Actions.MetaObject[])' differing only in ref or out, or in array rank, is not CLS-compliant /home/tinuviel/svn/ironpython/Src/Microsoft.Scripting/Actions/ComboBinder.cs(42,36): warning CS3006: Overloaded method `Microsoft.Scripting.Actions.ComboBinder.Bind(params Microsoft.Scripting.Actions.MetaObject[])' differing only in ref or out, or in array rank, is not CLS-compliant /home/tinuviel/svn/ironpython/Src/Microsoft.Scripting.Core/Actions/MetaAction.cs(159,36): (Location of the symbol related to previous warning) Otherwise, I am very happy to report that entire IronPython codebase is warning-free on Mono now! -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Fri Oct 10 20:17:30 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Sat, 11 Oct 2008 03:17:30 +0900 Subject: [IronPython] Warning CS3006 In-Reply-To: <350E7D38B6D819428718949920EC23554789335B89@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <5b0248170810082145p41ae340dx83bf8a3f1dc82247@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335B89@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <5b0248170810101117m741ede5bk62fcc7878121ea7c@mail.gmail.com> 2008/10/11 Dino Viehland : > It sure looks like it - are there more though? I'd expect one for each action kind. The methods differ in generic arity and the type of array they accept so at the very least the error string is wrong even if it is bad style to differ that way. I think mcs is warning that you have "params" there. GetMemberAction and ComboBinder are only ones with the signature: public override MetaObject Bind(params MetaObject[] args) and not: public override MetaObject Bind(MetaObject[] args) Other actions don't have "params" attribute and mcs doesn't warn about them. -- Seo Sanghyeon From dinov at microsoft.com Fri Oct 10 22:00:05 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 10 Oct 2008 13:00:05 -0700 Subject: [IronPython] Warning CS3006 In-Reply-To: <5b0248170810101117m741ede5bk62fcc7878121ea7c@mail.gmail.com> References: <5b0248170810082145p41ae340dx83bf8a3f1dc82247@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335B89@NA-EXMSG-C102.redmond.corp.microsoft.com> <5b0248170810101117m741ede5bk62fcc7878121ea7c@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23554789335C5E@NA-EXMSG-C102.redmond.corp.microsoft.com> Oh, that makes sense... The warning is certainly hard to understand but we should probably not do that :) -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Seo Sanghyeon Sent: Friday, October 10, 2008 11:18 AM To: Discussion of IronPython Subject: Re: [IronPython] Warning CS3006 2008/10/11 Dino Viehland : > It sure looks like it - are there more though? I'd expect one for each action kind. The methods differ in generic arity and the type of array they accept so at the very least the error string is wrong even if it is bad style to differ that way. I think mcs is warning that you have "params" there. GetMemberAction and ComboBinder are only ones with the signature: public override MetaObject Bind(params MetaObject[] args) and not: public override MetaObject Bind(MetaObject[] args) Other actions don't have "params" attribute and mcs doesn't warn about them. -- Seo Sanghyeon _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From Marty.Nelson at symyx.com Fri Oct 10 22:01:31 2008 From: Marty.Nelson at symyx.com (Marty Nelson) Date: Fri, 10 Oct 2008 13:01:31 -0700 Subject: [IronPython] Can I pre-add namespaces? Message-ID: <515335F32AA04440B3DE6FEA1993E9AD039BD2B0@srv-be-101.Symyx-IC.symyx.com> I know I can load assemblies into the script runtime, but how can I add the imports into the scope programmatically? I'm trying to avoid forcing people to write things like "imports System" for scripts. Microsoft.Scripting.Actions.NamespaceTracker seems to be involved, but it isn't there till after the scope executes for the first time and it has no public contructor. Thanks, - Marty ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Fri Oct 10 22:12:12 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 10 Oct 2008 13:12:12 -0700 Subject: [IronPython] Can I pre-add namespaces? In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD039BD2B0@srv-be-101.Symyx-IC.symyx.com> References: <515335F32AA04440B3DE6FEA1993E9AD039BD2B0@srv-be-101.Symyx-IC.symyx.com> Message-ID: <350E7D38B6D819428718949920EC23554789335C71@NA-EXMSG-C102.redmond.corp.microsoft.com> I think if you're not replacing Globals on the script runtime you can fetch the namespace from the ScriptRuntime.Globals scope. If that doesn't work for some reason you can always new up a TopNamespaceTracker, load assemblies into it, and get the namespace trackers from it. You'll need to get the the ScriptDomainManager object which you can fetch w/ the HostingHelpers.GetDomainManager function. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Friday, October 10, 2008 1:02 PM To: users at lists.ironpython.com Subject: [IronPython] Can I pre-add namespaces? I know I can load assemblies into the script runtime, but how can I add the imports into the scope programmatically? I'm trying to avoid forcing people to write things like "imports System" for scripts. Microsoft.Scripting.Actions.NamespaceTracker seems to be involved, but it isn't there till after the scope executes for the first time and it has no public contructor. Thanks, - Marty ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marty.Nelson at symyx.com Fri Oct 10 22:38:24 2008 From: Marty.Nelson at symyx.com (Marty Nelson) Date: Fri, 10 Oct 2008 13:38:24 -0700 Subject: [IronPython] Can I pre-add namespaces? In-Reply-To: <350E7D38B6D819428718949920EC23554789335C71@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <515335F32AA04440B3DE6FEA1993E9AD039BD2B0@srv-be-101.Symyx-IC.symyx.com> <350E7D38B6D819428718949920EC23554789335C71@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <515335F32AA04440B3DE6FEA1993E9AD039BD2D7@srv-be-101.Symyx-IC.symyx.com> Maybe it would it be easier just to append it to the text prior to execution. It didn't appear to have a side effect. Any performance considerations? ScriptSource scriptSource = engine.CreateScriptSourceFromString( "import System\r\n" + script, SourceCodeKind.Statements); scriptSource.Execute(scope); ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, October 10, 2008 1:12 PM To: Discussion of IronPython Subject: Re: [IronPython] Can I pre-add namespaces? I think if you're not replacing Globals on the script runtime you can fetch the namespace from the ScriptRuntime.Globals scope. If that doesn't work for some reason you can always new up a TopNamespaceTracker, load assemblies into it, and get the namespace trackers from it. You'll need to get the the ScriptDomainManager object which you can fetch w/ the HostingHelpers.GetDomainManager function. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Friday, October 10, 2008 1:02 PM To: users at lists.ironpython.com Subject: [IronPython] Can I pre-add namespaces? I know I can load assemblies into the script runtime, but how can I add the imports into the scope programmatically? I'm trying to avoid forcing people to write things like "imports System" for scripts. Microsoft.Scripting.Actions.NamespaceTracker seems to be involved, but it isn't there till after the scope executes for the first time and it has no public contructor. Thanks, - Marty ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Fri Oct 10 23:24:32 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 10 Oct 2008 14:24:32 -0700 Subject: [IronPython] Can I pre-add namespaces? In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD039BD2D7@srv-be-101.Symyx-IC.symyx.com> References: <515335F32AA04440B3DE6FEA1993E9AD039BD2B0@srv-be-101.Symyx-IC.symyx.com> <350E7D38B6D819428718949920EC23554789335C71@NA-EXMSG-C102.redmond.corp.microsoft.com> <515335F32AA04440B3DE6FEA1993E9AD039BD2D7@srv-be-101.Symyx-IC.symyx.com> Message-ID: <350E7D38B6D819428718949920EC23554789335CF0@NA-EXMSG-C102.redmond.corp.microsoft.com> That seems like a good solution, the perf should be fine. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Friday, October 10, 2008 1:38 PM To: Discussion of IronPython Subject: Re: [IronPython] Can I pre-add namespaces? Maybe it would it be easier just to append it to the text prior to execution. It didn't appear to have a side effect. Any performance considerations? ScriptSource scriptSource = engine.CreateScriptSourceFromString( "import System\r\n" + script, SourceCodeKind.Statements); scriptSource.Execute(scope); ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, October 10, 2008 1:12 PM To: Discussion of IronPython Subject: Re: [IronPython] Can I pre-add namespaces? I think if you're not replacing Globals on the script runtime you can fetch the namespace from the ScriptRuntime.Globals scope. If that doesn't work for some reason you can always new up a TopNamespaceTracker, load assemblies into it, and get the namespace trackers from it. You'll need to get the the ScriptDomainManager object which you can fetch w/ the HostingHelpers.GetDomainManager function. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Friday, October 10, 2008 1:02 PM To: users at lists.ironpython.com Subject: [IronPython] Can I pre-add namespaces? I know I can load assemblies into the script runtime, but how can I add the imports into the scope programmatically? I'm trying to avoid forcing people to write things like "imports System" for scripts. Microsoft.Scripting.Actions.NamespaceTracker seems to be involved, but it isn't there till after the scope executes for the first time and it has no public contructor. Thanks, - Marty ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marty.Nelson at symyx.com Fri Oct 10 23:40:01 2008 From: Marty.Nelson at symyx.com (Marty Nelson) Date: Fri, 10 Oct 2008 14:40:01 -0700 Subject: [IronPython] Can I pre-add namespaces? In-Reply-To: <350E7D38B6D819428718949920EC23554789335CF0@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <515335F32AA04440B3DE6FEA1993E9AD039BD2B0@srv-be-101.Symyx-IC.symyx.com><350E7D38B6D819428718949920EC23554789335C71@NA-EXMSG-C102.redmond.corp.microsoft.com><515335F32AA04440B3DE6FEA1993E9AD039BD2D7@srv-be-101.Symyx-IC.symyx.com> <350E7D38B6D819428718949920EC23554789335CF0@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <515335F32AA04440B3DE6FEA1993E9AD039BD313@srv-be-101.Symyx-IC.symyx.com> Except when I start including "from x import *" type statements, I start getting hundreds and hundres of variables. The following doesn't seem to work though. I am probably not understanding runtime.Globals: ScriptRuntime runtime = Python.CreateRuntime(); runtime.LoadAssembly(typeof(string).Assembly); runtime.LoadAssembly(typeof(Uri).Assembly); ScriptEngine engine = runtime.GetEngine("py"); string imports = @"from System import *"; engine.CreateScriptSourceFromString(imports, SourceCodeKind.Statements) .Execute(runtime.Globals); string script = @"myDate = DateTime.Now"; ScriptScope scope = runtime.CreateScope(); ScriptSource scriptSource = engine.CreateScriptSourceFromString( script, SourceCodeKind.Statements); scriptSource.Execute(scope); ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, October 10, 2008 2:25 PM To: Discussion of IronPython Subject: Re: [IronPython] Can I pre-add namespaces? That seems like a good solution, the perf should be fine. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Friday, October 10, 2008 1:38 PM To: Discussion of IronPython Subject: Re: [IronPython] Can I pre-add namespaces? Maybe it would it be easier just to append it to the text prior to execution. It didn't appear to have a side effect. Any performance considerations? ScriptSource scriptSource = engine.CreateScriptSourceFromString( "import System\r\n" + script, SourceCodeKind.Statements); scriptSource.Execute(scope); ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, October 10, 2008 1:12 PM To: Discussion of IronPython Subject: Re: [IronPython] Can I pre-add namespaces? I think if you're not replacing Globals on the script runtime you can fetch the namespace from the ScriptRuntime.Globals scope. If that doesn't work for some reason you can always new up a TopNamespaceTracker, load assemblies into it, and get the namespace trackers from it. You'll need to get the the ScriptDomainManager object which you can fetch w/ the HostingHelpers.GetDomainManager function. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Friday, October 10, 2008 1:02 PM To: users at lists.ironpython.com Subject: [IronPython] Can I pre-add namespaces? I know I can load assemblies into the script runtime, but how can I add the imports into the scope programmatically? I'm trying to avoid forcing people to write things like "imports System" for scripts. Microsoft.Scripting.Actions.NamespaceTracker seems to be involved, but it isn't there till after the scope executes for the first time and it has no public contructor. Thanks, - Marty ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Fri Oct 10 23:46:53 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 10 Oct 2008 14:46:53 -0700 Subject: [IronPython] Can I pre-add namespaces? In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD039BD313@srv-be-101.Symyx-IC.symyx.com> References: <515335F32AA04440B3DE6FEA1993E9AD039BD2B0@srv-be-101.Symyx-IC.symyx.com><350E7D38B6D819428718949920EC23554789335C71@NA-EXMSG-C102.redmond.corp.microsoft.com><515335F32AA04440B3DE6FEA1993E9AD039BD2D7@srv-be-101.Symyx-IC.symyx.com> <350E7D38B6D819428718949920EC23554789335CF0@NA-EXMSG-C102.redmond.corp.microsoft.com> <515335F32AA04440B3DE6FEA1993E9AD039BD313@srv-be-101.Symyx-IC.symyx.com> Message-ID: <350E7D38B6D819428718949920EC23554789335D11@NA-EXMSG-C102.redmond.corp.microsoft.com> I was thinking more of just runtime.Globals.TryGetVariable() and then injecting the object you get there into the scope you'll run the code against. >From x import * will tend to pollute your namespace and therefore isn't that great (it also makes it harder when reading the code to know where your imports came from). So something like: if(runtime.Globals.TryGetVariable("System", out value)) { scope.SetVariable("System", value); } From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Friday, October 10, 2008 2:40 PM To: Discussion of IronPython Subject: Re: [IronPython] Can I pre-add namespaces? Except when I start including "from x import *" type statements, I start getting hundreds and hundres of variables. The following doesn't seem to work though. I am probably not understanding runtime.Globals: ScriptRuntime runtime = Python.CreateRuntime(); runtime.LoadAssembly(typeof(string).Assembly); runtime.LoadAssembly(typeof(Uri).Assembly); ScriptEngine engine = runtime.GetEngine("py"); string imports = @"from System import *"; engine.CreateScriptSourceFromString(imports, SourceCodeKind.Statements) .Execute(runtime.Globals); string script = @"myDate = DateTime.Now"; ScriptScope scope = runtime.CreateScope(); ScriptSource scriptSource = engine.CreateScriptSourceFromString( script, SourceCodeKind.Statements); scriptSource.Execute(scope); ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, October 10, 2008 2:25 PM To: Discussion of IronPython Subject: Re: [IronPython] Can I pre-add namespaces? That seems like a good solution, the perf should be fine. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Friday, October 10, 2008 1:38 PM To: Discussion of IronPython Subject: Re: [IronPython] Can I pre-add namespaces? Maybe it would it be easier just to append it to the text prior to execution. It didn't appear to have a side effect. Any performance considerations? ScriptSource scriptSource = engine.CreateScriptSourceFromString( "import System\r\n" + script, SourceCodeKind.Statements); scriptSource.Execute(scope); ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, October 10, 2008 1:12 PM To: Discussion of IronPython Subject: Re: [IronPython] Can I pre-add namespaces? I think if you're not replacing Globals on the script runtime you can fetch the namespace from the ScriptRuntime.Globals scope. If that doesn't work for some reason you can always new up a TopNamespaceTracker, load assemblies into it, and get the namespace trackers from it. You'll need to get the the ScriptDomainManager object which you can fetch w/ the HostingHelpers.GetDomainManager function. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Friday, October 10, 2008 1:02 PM To: users at lists.ironpython.com Subject: [IronPython] Can I pre-add namespaces? I know I can load assemblies into the script runtime, but how can I add the imports into the scope programmatically? I'm trying to avoid forcing people to write things like "imports System" for scripts. Microsoft.Scripting.Actions.NamespaceTracker seems to be involved, but it isn't there till after the scope executes for the first time and it has no public contructor. Thanks, - Marty ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From desleo at gmail.com Fri Oct 10 23:49:50 2008 From: desleo at gmail.com (Leo Carbajal) Date: Fri, 10 Oct 2008 16:49:50 -0500 Subject: [IronPython] Can I pre-add namespaces? In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD039BD2D7@srv-be-101.Symyx-IC.symyx.com> References: <515335F32AA04440B3DE6FEA1993E9AD039BD2B0@srv-be-101.Symyx-IC.symyx.com> <350E7D38B6D819428718949920EC23554789335C71@NA-EXMSG-C102.redmond.corp.microsoft.com> <515335F32AA04440B3DE6FEA1993E9AD039BD2D7@srv-be-101.Symyx-IC.symyx.com> Message-ID: Would it be possible to use scriptSource.IncludeFile(path) instead to get the same effect? I was perusing the hostingAPI and the Runtime has a whole paragraph for UseFile but when you look at the class declaration (again on the hostingAPI doc) it's not listed there, so I'm not sure if that's just a leftover ghost - I can't confirm it from work. Mostly I'm curious about the first, as thats how I would have approached it. On Fri, Oct 10, 2008 at 3:38 PM, Marty Nelson wrote: > Maybe it would it be easier just to append it to the text prior to > execution. It didn't appear to have a side effect. Any performance > considerations? > > > > ScriptSource scriptSource = engine.CreateScriptSourceFromString( > > "import System\r\n" + script, SourceCodeKind.Statements); > > scriptSource.Execute(scope); > > > > > ------------------------------ > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Dino Viehland > *Sent:* Friday, October 10, 2008 1:12 PM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Can I pre-add namespaces? > > > > I think if you're not replacing Globals on the script runtime you can fetch > the namespace from the ScriptRuntime.Globals scope. > > > > If that doesn't work for some reason you can always new up a > TopNamespaceTracker, load assemblies into it, and get the namespace trackers > from it. You'll need to get the the ScriptDomainManager object which you > can fetch w/ the HostingHelpers.GetDomainManager function. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Marty Nelson > *Sent:* Friday, October 10, 2008 1:02 PM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Can I pre-add namespaces? > > > > I know I can load assemblies into the script runtime, but how can I add the > imports into the scope programmatically? I'm trying to avoid forcing people > to write things like "imports System" for scripts. > > > > Microsoft.Scripting.Actions.NamespaceTracker seems to be involved, but it > isn't there till after the scope executes for the first time and it has no > public contructor. > > > > Thanks, > > > > - Marty > > ======= > Notice: This e-mail message, together with any attachments, contains > information of Symyx Technologies, Inc. or any of its affiliates or > subsidiaries that may be confidential, proprietary, copyrighted, > privileged and/or protected work product, and is meant solely for > the intended recipient. If you are not the intended recipient, and > have received this message in error, please contact the sender > immediately, permanently delete the original and any copies of this > email and any attachments thereto. > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Sat Oct 11 01:44:37 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 10 Oct 2008 16:44:37 -0700 Subject: [IronPython] Can I pre-add namespaces? In-Reply-To: References: <515335F32AA04440B3DE6FEA1993E9AD039BD2B0@srv-be-101.Symyx-IC.symyx.com> <350E7D38B6D819428718949920EC23554789335C71@NA-EXMSG-C102.redmond.corp.microsoft.com> <515335F32AA04440B3DE6FEA1993E9AD039BD2D7@srv-be-101.Symyx-IC.symyx.com> Message-ID: <350E7D38B6D819428718949920EC23554789335DF0@NA-EXMSG-C102.redmond.corp.microsoft.com> UseFile is about just running a piece of code that lives somewhere the language can find (on sys.path for Python) and returning the new ScriptScope that it was executed in - it doesn't do anything with namespaces so it won't help here. It's supposed to be an easy way to just run some one-off code. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Leo Carbajal Sent: Friday, October 10, 2008 2:50 PM To: Discussion of IronPython Subject: Re: [IronPython] Can I pre-add namespaces? Would it be possible to use scriptSource.IncludeFile(path) instead to get the same effect? I was perusing the hostingAPI and the Runtime has a whole paragraph for UseFile but when you look at the class declaration (again on the hostingAPI doc) it's not listed there, so I'm not sure if that's just a leftover ghost - I can't confirm it from work. Mostly I'm curious about the first, as thats how I would have approached it. On Fri, Oct 10, 2008 at 3:38 PM, Marty Nelson > wrote: Maybe it would it be easier just to append it to the text prior to execution. It didn't appear to have a side effect. Any performance considerations? ScriptSource scriptSource = engine.CreateScriptSourceFromString( "import System\r\n" + script, SourceCodeKind.Statements); scriptSource.Execute(scope); ________________________________ From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, October 10, 2008 1:12 PM To: Discussion of IronPython Subject: Re: [IronPython] Can I pre-add namespaces? I think if you're not replacing Globals on the script runtime you can fetch the namespace from the ScriptRuntime.Globals scope. If that doesn't work for some reason you can always new up a TopNamespaceTracker, load assemblies into it, and get the namespace trackers from it. You'll need to get the the ScriptDomainManager object which you can fetch w/ the HostingHelpers.GetDomainManager function. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson Sent: Friday, October 10, 2008 1:02 PM To: users at lists.ironpython.com Subject: [IronPython] Can I pre-add namespaces? I know I can load assemblies into the script runtime, but how can I add the imports into the scope programmatically? I'm trying to avoid forcing people to write things like "imports System" for scripts. Microsoft.Scripting.Actions.NamespaceTracker seems to be involved, but it isn't there till after the scope executes for the first time and it has no public contructor. Thanks, - Marty ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfugate at microsoft.com Sat Oct 11 01:55:38 2008 From: dfugate at microsoft.com (Dave Fugate) Date: Fri, 10 Oct 2008 16:55:38 -0700 Subject: [IronPython] What happened to source drops? References: <4817b6fc0809291323k52a7dc6cj9976fcb5ac6ce290@mail.gmail.com> <350E7D38B6D819428718949920EC235547877B9A24@NA-EXMSG-C102.redmond.corp.microsoft.com> <48E14564.1050403@voidspace.org.uk> <350E7D38B6D819428718949920EC235547877B9A48@NA-EXMSG-C102.redmond.corp.microsoft.com> <48E148C3.9030207@voidspace.org.uk> <350E7D38B6D819428718949920EC235547877B9A65@NA-EXMSG-C102.redmond.corp.microsoft.com> <48E27B15.3010701@voidspace.org.uk> Message-ID: The sources have just been updated and I believe this includes the changes you wanted. Dave -----Original Message----- From: Dave Fugate Sent: Wednesday, October 01, 2008 8:52 AM To: Discussion of IronPython Subject: RE: [IronPython] What happened to source drops? My best guess is the fixes will be in the 2.0 branch sometime next week. Offhand, I don't believe the package/module compiling fixes are in yet (e.g., the cyclic dependencies bug is fixed in 2.1, but not 2.0). Dave -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Tuesday, September 30, 2008 12:17 PM To: Discussion of IronPython Subject: Re: [IronPython] What happened to source drops? Dave Fugate wrote: > Actually there was a little confusion internally and the 40877 changeset uploaded to CodePlex yesterday corresponds to our new IronPython 2.1 branch. In turn, the 2.1 branch was the reason there's been no source pushes for the past two weeks - some scripts and TFS enlistments needed updating to re-enable IP 2.0 source updates. > > The latest update, changeset 40917, comes from our IronPython 2.0 branch and does not yet include most of the fixes in changeset 40877. If you want these now (and possibly some changes that won't be making it into IP 2.0), use http://www.codeplex.com/IronPython/SourceControl/DownloadSourceCode.aspx?changeSetId=40877. Otherwise, we hope to have the fixes included in TFS within a week. Sorry for any confusion about this. > > No problem. Any ETA on getting the features that will make it in to 2.0 available in a code drop? Are the 'compiling packages' fixes in the current 2.0 branch code drop? Michael > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Srivatsn Narayanan > Sent: Monday, September 29, 2008 3:12 PM > To: Discussion of IronPython > Subject: Re: [IronPython] What happened to source drops? > > I've pushed out a source drop with the latest sources - http://www.codeplex.com/IronPython/SourceControl/ListDownloadableCommits.aspx > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland > Sent: Monday, September 29, 2008 2:40 PM > To: Discussion of IronPython > Subject: Re: [IronPython] What happened to source drops? > > I would actually suggest compiling the standard modules as well as your code and then ngen them both on install. You can compile the std modules into their own .dll so the user can always replace them w/ their own version (or they can simply delete the DLL and then pick up the .py files). > > The reason I suggest this is with the bits on my machine I'm seeing massive import speed ups w/ pre-compilation + ngen (e.g. 3x or so). > > And decimal does import a lot more - but the real working set hit came from publishing all the SymbolIDs for every precompiled module - once for each module - on startup! A small oversight :)... But there were a few other areas that could use some improvement as well. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, September 29, 2008 2:30 PM > To: Discussion of IronPython > Subject: Re: [IronPython] What happened to source drops? > > Dino Viehland wrote: > >> They're checked in so they'll be in the next source push. There are some perf problems that I have fixes for though that aren't checked in (e.g. import decimal in pre-compiled currently allocates ~550MB of memory) - but you should be able to do functional testing :). I'll should have the pre-comp perf fixes in this week. >> >> > > Cool - thanks. 550mb for one module - wow. Good job we aren't intending > to precompile the Python standard library modules we're using. Having > said that we have quite a chunk of Python source we would like to > compile - I wonder if a 4gb address space will be enough. I think we > will be reluctant to move to 64bit oses only... ;-) > > Michael > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Monday, September 29, 2008 2:15 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] What happened to source drops? >> >> Dino Viehland wrote: >> >> >>> It looks like the script which automatically publishes the code has stopped publishing the updates. Dave's OOF today and I can't find the original instructions but Sri's looking into it. >>> >>> >>> >> Cool. If you get the compiling packages fixes into a code drop please >> let me know so that we can start testing them early. >> >> Thanks >> >> Michael Foord >> >> >> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff >>> Sent: Monday, September 29, 2008 1:23 PM >>> To: Discussion of IronPython >>> Subject: [IronPython] What happened to source drops? >>> >>> I'm noticing that the last source drop was the beta 5 release two weeks ago. >>> >>> I don't mean to pressure you guys, but I am looking forward to the >>> next source release, which seems to have the delegate regressions >>> fixed. Any (vague) idea of when regular source drops will be resumed? >>> >>> By the way, I built IronPython b5 for Silverlight RC0, and I had to >>> modify Microsoft.Scripting.Silverlight.ErrorFormatter: >>> >>> - HtmlPage.Document.GetElementsByTagName("body")[0].AppendChild(target); >>> + ((HtmlElement)HtmlPage.Document.GetElementsByTagName("body")[0]).AppendChild(target); >>> >>> I'm not fully sure how this code compiled in the first place, as >>> ScriptObject never had an AppendChild method. Probably this code has >>> already been fixed, but it's worth checking anyway. >>> >>> -Dan >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >> -- >> http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/ >> http://www.trypython.org/ >> http://www.ironpython.info/ >> http://www.theotherdelia.co.uk/ >> http://www.resolverhacks.net/ >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.theotherdelia.co.uk/ > http://www.resolverhacks.net/ > > _______________________________________________ > 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 > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.net/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dan.eloff at gmail.com Sat Oct 11 22:29:09 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Sat, 11 Oct 2008 15:29:09 -0500 Subject: [IronPython] Why would you use MakeList over MakeListNoCopy? Message-ID: <4817b6fc0810111329q13c42668j36e7aea20c47ed80@mail.gmail.com> /// /// Python runtime helper to create a populated instance of Python List object. /// public static List MakeList(params object[] items) { return new List(items); } /// /// Python runtime helper to create a populated instance of Python List object w/o /// copying the array contents. /// [NoSideEffects] public static List MakeListNoCopy(params object[] items) { return List.FromArrayNoCopy(items); } If the second method "just works" then why would you ever want to use MakeList? I seem to be creating a lot of 1 and 2 item lists here, so I'm looking to make good use of one of these guys. (I really miss C# 3.0 collection initializers) Work on porting _ast is going well, so far I've had no insurmountable obstacles. I expect to be done it by Monday. The AST produced is close (but not identical) to CPython, but that shouldn't matter. Each node has the same properties with the exact same types so walking the tree should work equally on both platforms. Thanks, -Dan From dinov at microsoft.com Sat Oct 11 22:38:31 2008 From: dinov at microsoft.com (Dino Viehland) Date: Sat, 11 Oct 2008 13:38:31 -0700 Subject: [IronPython] Why would you use MakeList over MakeListNoCopy? In-Reply-To: <4817b6fc0810111329q13c42668j36e7aea20c47ed80@mail.gmail.com> References: <4817b6fc0810111329q13c42668j36e7aea20c47ed80@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23554789335E71@NA-EXMSG-C102.redmond.corp.microsoft.com> The difference is whether or not you're the owner of the array. If you've accepted the array from some public location, even if it was a params method, someone else could own the array and continue to modify it. If you've created the array yourself or can guarantee it won't change then it can safely be used for the underlying object array for the List object. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff Sent: Saturday, October 11, 2008 1:29 PM To: Discussion of IronPython Subject: [IronPython] Why would you use MakeList over MakeListNoCopy? /// /// Python runtime helper to create a populated instance of Python List object. /// public static List MakeList(params object[] items) { return new List(items); } /// /// Python runtime helper to create a populated instance of Python List object w/o /// copying the array contents. /// [NoSideEffects] public static List MakeListNoCopy(params object[] items) { return List.FromArrayNoCopy(items); } If the second method "just works" then why would you ever want to use MakeList? I seem to be creating a lot of 1 and 2 item lists here, so I'm looking to make good use of one of these guys. (I really miss C# 3.0 collection initializers) Work on porting _ast is going well, so far I've had no insurmountable obstacles. I expect to be done it by Monday. The AST produced is close (but not identical) to CPython, but that shouldn't matter. Each node has the same properties with the exact same types so walking the tree should work equally on both platforms. Thanks, -Dan _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dan.eloff at gmail.com Sat Oct 11 22:59:46 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Sat, 11 Oct 2008 15:59:46 -0500 Subject: [IronPython] Why would you use MakeList over MakeListNoCopy? In-Reply-To: <350E7D38B6D819428718949920EC23554789335E71@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <4817b6fc0810111329q13c42668j36e7aea20c47ed80@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335E71@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <4817b6fc0810111359h1e61f5b9r3254599ed7a42785@mail.gmail.com> On Sat, Oct 11, 2008 at 3:38 PM, Dino Viehland wrote: > The difference is whether or not you're the owner of the array. If you've accepted the array from some public location, even if it was a params method, someone else could own the array and continue to modify it. If you've created the array yourself or can guarantee it won't change then it can safely be used for the underlying object array for the List object. That's what I figured about 5 minutes after I sent the email :( This stuff is burning my brain. One thing that is unclear to me, if you do l = MakeListNoCopy(x, y), is it legal to do l[0] = z ? It seems a little shaky to me, but if mutating a params array is legal in C#, then I suppose it shouldn't break. Thanks, -Dan > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff > Sent: Saturday, October 11, 2008 1:29 PM > To: Discussion of IronPython > Subject: [IronPython] Why would you use MakeList over MakeListNoCopy? > > /// > /// Python runtime helper to create a populated instance of > Python List object. > /// > public static List MakeList(params object[] items) { > return new List(items); > } > > /// > /// Python runtime helper to create a populated instance of > Python List object w/o > /// copying the array contents. > /// > [NoSideEffects] > public static List MakeListNoCopy(params object[] items) { > return List.FromArrayNoCopy(items); > } > > If the second method "just works" then why would you ever want to use MakeList? > > I seem to be creating a lot of 1 and 2 item lists here, so I'm looking > to make good use of one of these guys. (I really miss C# 3.0 > collection initializers) > > Work on porting _ast is going well, so far I've had no insurmountable > obstacles. I expect to be done it by Monday. The AST produced is close > (but not identical) to CPython, but that shouldn't matter. Each node > has the same properties with the exact same types so walking the tree > should work equally on both platforms. > > Thanks, > -Dan > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > From dinov at microsoft.com Sat Oct 11 23:01:34 2008 From: dinov at microsoft.com (Dino Viehland) Date: Sat, 11 Oct 2008 14:01:34 -0700 Subject: [IronPython] Why would you use MakeList over MakeListNoCopy? In-Reply-To: <4817b6fc0810111359h1e61f5b9r3254599ed7a42785@mail.gmail.com> References: <4817b6fc0810111329q13c42668j36e7aea20c47ed80@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335E71@NA-EXMSG-C102.redmond.corp.microsoft.com> <4817b6fc0810111359h1e61f5b9r3254599ed7a42785@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23554789335E74@NA-EXMSG-C102.redmond.corp.microsoft.com> Yep, that's fine - C# creates a new array on every params call. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff Sent: Saturday, October 11, 2008 2:00 PM To: Discussion of IronPython Subject: Re: [IronPython] Why would you use MakeList over MakeListNoCopy? On Sat, Oct 11, 2008 at 3:38 PM, Dino Viehland wrote: > The difference is whether or not you're the owner of the array. If you've accepted the array from some public location, even if it was a params method, someone else could own the array and continue to modify it. If you've created the array yourself or can guarantee it won't change then it can safely be used for the underlying object array for the List object. That's what I figured about 5 minutes after I sent the email :( This stuff is burning my brain. One thing that is unclear to me, if you do l = MakeListNoCopy(x, y), is it legal to do l[0] = z ? It seems a little shaky to me, but if mutating a params array is legal in C#, then I suppose it shouldn't break. Thanks, -Dan > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff > Sent: Saturday, October 11, 2008 1:29 PM > To: Discussion of IronPython > Subject: [IronPython] Why would you use MakeList over MakeListNoCopy? > > /// > /// Python runtime helper to create a populated instance of > Python List object. > /// > public static List MakeList(params object[] items) { > return new List(items); > } > > /// > /// Python runtime helper to create a populated instance of > Python List object w/o > /// copying the array contents. > /// > [NoSideEffects] > public static List MakeListNoCopy(params object[] items) { > return List.FromArrayNoCopy(items); > } > > If the second method "just works" then why would you ever want to use MakeList? > > I seem to be creating a lot of 1 and 2 item lists here, so I'm looking > to make good use of one of these guys. (I really miss C# 3.0 > collection initializers) > > Work on porting _ast is going well, so far I've had no insurmountable > obstacles. I expect to be done it by Monday. The AST produced is close > (but not identical) to CPython, but that shouldn't matter. Each node > has the same properties with the exact same types so walking the tree > should work equally on both platforms. > > Thanks, > -Dan > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From asaf at itstructures.com Sun Oct 12 11:27:18 2008 From: asaf at itstructures.com (Asaf Kleinbort) Date: Sun, 12 Oct 2008 11:27:18 +0200 Subject: [IronPython] Problem with random module in IPY 1.1.1 Message-ID: <003001c92c4c$baad3560$3007a020$@com> Hi, We have encountered two strange errors in the 'random' module: 1. At some point the random method 'getrandbits(63)' started (and kept) returning 0 - until we restarted the application. 2. The random method 'shuffle' when applied on a list kept returning the same ordered list. Again - restarting the application solved the problem An interesting remark is that issue #1 happened to us today in two different applications, around the same time. Any ideas? Thanks, Asaf -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangym at gmail.com Sun Oct 12 14:49:57 2008 From: wangym at gmail.com (Yongming) Date: Sun, 12 Oct 2008 05:49:57 -0700 (PDT) Subject: [IronPython] Debug IP script embedded in c# application Message-ID: <1926d750-8f20-43f1-b552-082e0c96a925@v16g2000prc.googlegroups.com> Hello, I tried to extend my c# application with IronPython 2.0 scripts. So an IDE was wanted to debug the scripts. I tried the ways Michael mentioned here, but it didn't work for me. http://tech-michael.blogspot.com/2008/07/i-was-charged-by-company-i-work-for-to.html Did anyone tried his way, did it worked with IP 2.0? Or any other tools I can use to debug my scripts? From dinov at microsoft.com Sun Oct 12 17:49:43 2008 From: dinov at microsoft.com (Dino Viehland) Date: Sun, 12 Oct 2008 08:49:43 -0700 Subject: [IronPython] Debug IP script embedded in c# application In-Reply-To: <1926d750-8f20-43f1-b552-082e0c96a925@v16g2000prc.googlegroups.com> References: <1926d750-8f20-43f1-b552-082e0c96a925@v16g2000prc.googlegroups.com> Message-ID: <350E7D38B6D819428718949920EC23554789335EF5@NA-EXMSG-C102.redmond.corp.microsoft.com> Did you set DebugMore = true on a ScriptRuntimeSetup object? If you're using the Python class you can pass a Dictionary object to CreateRuntime with "Debug" = "true" and we'll set it for you. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Yongming Sent: Sunday, October 12, 2008 5:50 AM To: users at lists.ironpython.com Subject: [IronPython] Debug IP script embedded in c# application Hello, I tried to extend my c# application with IronPython 2.0 scripts. So an IDE was wanted to debug the scripts. I tried the ways Michael mentioned here, but it didn't work for me. http://tech-michael.blogspot.com/2008/07/i-was-charged-by-company-i-work-for-to.html Did anyone tried his way, did it worked with IP 2.0? Or any other tools I can use to debug my scripts? _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From r.worbis at cubido.at Sun Oct 12 21:10:22 2008 From: r.worbis at cubido.at (Rainer Worbis) Date: Sun, 12 Oct 2008 21:10:22 +0200 Subject: [IronPython] Debugging IronPython script code Message-ID: <676F9CCC1D1D3242BE4B133746E3807E53CD65@XARA.cubido.linz> Hallo all, is there a possibility to debug IronPython code that is executed with ScriptSource.Execute or CompiledCode.Execute within VisualStudio? Setting breakpoints in the python code will can be done by System.Diagnostics.Debugger.Break() - the code breaks but I don't know how to tell VS to get into my code. Rainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Sun Oct 12 21:21:20 2008 From: dinov at microsoft.com (Dino Viehland) Date: Sun, 12 Oct 2008 12:21:20 -0700 Subject: [IronPython] Debugging IronPython script code In-Reply-To: <676F9CCC1D1D3242BE4B133746E3807E53CD65@XARA.cubido.linz> References: <676F9CCC1D1D3242BE4B133746E3807E53CD65@XARA.cubido.linz> Message-ID: <350E7D38B6D819428718949920EC23554789335EFA@NA-EXMSG-C102.redmond.corp.microsoft.com> You can set DebugMode = true on a ScriptRuntimeSetup object. If you're using the Python class you can pass a Dictionary object to CreateRuntime with "Debug" = "true" and we'll set it for you. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 12:10 PM To: Users at lists.ironpython.com Subject: [IronPython] Debugging IronPython script code Hallo all, is there a possibility to debug IronPython code that is executed with ScriptSource.Execute or CompiledCode.Execute within VisualStudio? Setting breakpoints in the python code will can be done by System.Diagnostics.Debugger.Break() - the code breaks but I don't know how to tell VS to get into my code. Rainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.mulot at free.fr Sun Oct 12 22:53:46 2008 From: g.mulot at free.fr (Gerard Mulot) Date: Sun, 12 Oct 2008 22:53:46 +0200 Subject: [IronPython] LeeBeLLuL and Google App EngineIronPython, Message-ID: <000001c92cac$a20d0890$e62719b0$@mulot@free.fr> A demo of LeeBeLLuL with Google App Engine is available. http://www.leebellul.com/Site/APPLICATIONS/Ressources_Humaines_V1.html Regards LeeBeLLuL -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.worbis at cubido.at Mon Oct 13 06:52:53 2008 From: r.worbis at cubido.at (Rainer Worbis) Date: Mon, 13 Oct 2008 06:52:53 +0200 Subject: [IronPython] Debugging IronPython script code In-Reply-To: <350E7D38B6D819428718949920EC23554789335EFA@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <676F9CCC1D1D3242BE4B133746E3807E53CD65@XARA.cubido.linz> <350E7D38B6D819428718949920EC23554789335EFA@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <676F9CCC1D1D3242BE4B133746E3807E53CD68@XARA.cubido.linz> I got as far as that - when the breakpoint is hit - VS pops up but not in some python code but in the call to Execute - the python code is marked as external code. So is there a possibility to have VS show the script code? Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Sonntag, 12. Oktober 2008 21:21 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code You can set DebugMode = true on a ScriptRuntimeSetup object. If you're using the Python class you can pass a Dictionary object to CreateRuntime with "Debug" = "true" and we'll set it for you. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 12:10 PM To: Users at lists.ironpython.com Subject: [IronPython] Debugging IronPython script code Hallo all, is there a possibility to debug IronPython code that is executed with ScriptSource.Execute or CompiledCode.Execute within VisualStudio? Setting breakpoints in the python code will can be done by System.Diagnostics.Debugger.Break() - the code breaks but I don't know how to tell VS to get into my code. Rainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Oct 13 06:54:45 2008 From: dinov at microsoft.com (Dino Viehland) Date: Sun, 12 Oct 2008 21:54:45 -0700 Subject: [IronPython] Debugging IronPython script code In-Reply-To: <676F9CCC1D1D3242BE4B133746E3807E53CD68@XARA.cubido.linz> References: <676F9CCC1D1D3242BE4B133746E3807E53CD65@XARA.cubido.linz> <350E7D38B6D819428718949920EC23554789335EFA@NA-EXMSG-C102.redmond.corp.microsoft.com> <676F9CCC1D1D3242BE4B133746E3807E53CD68@XARA.cubido.linz> Message-ID: <350E7D38B6D819428718949920EC23554789335F3D@NA-EXMSG-C102.redmond.corp.microsoft.com> If you right click in the call stack window and check Show External Code do you see the code then? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 9:53 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code I got as far as that - when the breakpoint is hit - VS pops up but not in some python code but in the call to Execute - the python code is marked as external code. So is there a possibility to have VS show the script code? Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Sonntag, 12. Oktober 2008 21:21 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code You can set DebugMode = true on a ScriptRuntimeSetup object. If you're using the Python class you can pass a Dictionary object to CreateRuntime with "Debug" = "true" and we'll set it for you. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 12:10 PM To: Users at lists.ironpython.com Subject: [IronPython] Debugging IronPython script code Hallo all, is there a possibility to debug IronPython code that is executed with ScriptSource.Execute or CompiledCode.Execute within VisualStudio? Setting breakpoints in the python code will can be done by System.Diagnostics.Debugger.Break() - the code breaks but I don't know how to tell VS to get into my code. Rainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.worbis at cubido.at Mon Oct 13 07:01:35 2008 From: r.worbis at cubido.at (Rainer Worbis) Date: Mon, 13 Oct 2008 07:01:35 +0200 Subject: [IronPython] Debugging IronPython script code In-Reply-To: <350E7D38B6D819428718949920EC23554789335F3D@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <676F9CCC1D1D3242BE4B133746E3807E53CD65@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789335EFA@NA-EXMSG-C102.redmond.corp.microsoft.com><676F9CCC1D1D3242BE4B133746E3807E53CD68@XARA.cubido.linz> <350E7D38B6D819428718949920EC23554789335F3D@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <676F9CCC1D1D3242BE4B133746E3807E53CD69@XARA.cubido.linz> No - i get the Call Stack showed below [Lightweight Function] > Microsoft.Scripting.dll!Microsoft.Scripting.Runtime.OptimizedScriptCode. InvokeTarget(Microsoft.Linq.Expressions.LambdaExpression code = {Microsoft.Linq.Expressions.Expression}, Microsoft.Scripting.Runtime.Scope scope = {Microsoft.Scripting.Runtime.Scope}) + 0x1c6 bytes Microsoft.Scripting.dll!Microsoft.Scripting.ScriptCode.Run(Microsoft.Scr ipting.Runtime.Scope scope = {Microsoft.Scripting.Runtime.Scope}) + 0x42 bytes Microsoft.Scripting.dll!Microsoft.Scripting.Hosting.CompiledCode.Execute (Microsoft.Scripting.Hosting.ScriptScope scope = {Microsoft.Scripting.Hosting.ScriptScope}) + 0x77 bytes ... Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Montag, 13. Oktober 2008 06:55 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code If you right click in the call stack window and check Show External Code do you see the code then? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 9:53 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code I got as far as that - when the breakpoint is hit - VS pops up but not in some python code but in the call to Execute - the python code is marked as external code. So is there a possibility to have VS show the script code? Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Sonntag, 12. Oktober 2008 21:21 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code You can set DebugMode = true on a ScriptRuntimeSetup object. If you're using the Python class you can pass a Dictionary object to CreateRuntime with "Debug" = "true" and we'll set it for you. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 12:10 PM To: Users at lists.ironpython.com Subject: [IronPython] Debugging IronPython script code Hallo all, is there a possibility to debug IronPython code that is executed with ScriptSource.Execute or CompiledCode.Execute within VisualStudio? Setting breakpoints in the python code will can be done by System.Diagnostics.Debugger.Break() - the code breaks but I don't know how to tell VS to get into my code. Rainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Oct 13 07:14:43 2008 From: dinov at microsoft.com (Dino Viehland) Date: Sun, 12 Oct 2008 22:14:43 -0700 Subject: [IronPython] Debugging IronPython script code In-Reply-To: <676F9CCC1D1D3242BE4B133746E3807E53CD69@XARA.cubido.linz> References: <676F9CCC1D1D3242BE4B133746E3807E53CD65@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789335EFA@NA-EXMSG-C102.redmond.corp.microsoft.com><676F9CCC1D1D3242BE4B133746E3807E53CD68@XARA.cubido.linz> <350E7D38B6D819428718949920EC23554789335F3D@NA-EXMSG-C102.redmond.corp.microsoft.com> <676F9CCC1D1D3242BE4B133746E3807E53CD69@XARA.cubido.linz> Message-ID: <350E7D38B6D819428718949920EC23554789335F3F@NA-EXMSG-C102.redmond.corp.microsoft.com> Oh, sorry, it looks like it needs to be a bool, not "true" in quotes... With that in mind this works for me: Dictionary options = new Dictionary(); options["Debug"] = true; ScriptEngine engine = Python.CreateEngine(options); ScriptSource source = engine.CreateScriptSourceFromFile("C:\\Users\\Dino\\test.py"); source.Execute(); I can put breakpoints in test.py and hit them. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 10:02 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code No - i get the Call Stack showed below [Lightweight Function] > Microsoft.Scripting.dll!Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(Microsoft.Linq.Expressions.LambdaExpression code = {Microsoft.Linq.Expressions.Expression}, Microsoft.Scripting.Runtime.Scope scope = {Microsoft.Scripting.Runtime.Scope}) + 0x1c6 bytes Microsoft.Scripting.dll!Microsoft.Scripting.ScriptCode.Run(Microsoft.Scripting.Runtime.Scope scope = {Microsoft.Scripting.Runtime.Scope}) + 0x42 bytes Microsoft.Scripting.dll!Microsoft.Scripting.Hosting.CompiledCode.Execute(Microsoft.Scripting.Hosting.ScriptScope scope = {Microsoft.Scripting.Hosting.ScriptScope}) + 0x77 bytes ... Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Montag, 13. Oktober 2008 06:55 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code If you right click in the call stack window and check Show External Code do you see the code then? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 9:53 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code I got as far as that - when the breakpoint is hit - VS pops up but not in some python code but in the call to Execute - the python code is marked as external code. So is there a possibility to have VS show the script code? Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Sonntag, 12. Oktober 2008 21:21 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code You can set DebugMode = true on a ScriptRuntimeSetup object. If you're using the Python class you can pass a Dictionary object to CreateRuntime with "Debug" = "true" and we'll set it for you. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 12:10 PM To: Users at lists.ironpython.com Subject: [IronPython] Debugging IronPython script code Hallo all, is there a possibility to debug IronPython code that is executed with ScriptSource.Execute or CompiledCode.Execute within VisualStudio? Setting breakpoints in the python code will can be done by System.Diagnostics.Debugger.Break() - the code breaks but I don't know how to tell VS to get into my code. Rainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jslutter at reactorzero.com Mon Oct 13 07:19:44 2008 From: jslutter at reactorzero.com (Jeff Slutter) Date: Mon, 13 Oct 2008 01:19:44 -0400 Subject: [IronPython] "Merlin" tutorial not working Message-ID: <48F2DA70.60202@reactorzero.com> I'm going through the IronPython tutorial and I'm at the COM interop part. I'm trying to get the Merlin example working but I can't get it past a certain part. First of all, I had to make some changes to get the example to work, as it doesn't appear the tuple/out param stuff works the same as it does in the tutorial. Here is my code: agentServer = AgentServerClass(); characterId = clr.Reference[int](); reqId = clr.Reference[int](); agentServer.Load("Merlin.acs", characterId, reqId); myMerlinCharacter = clr.Reference[object](); agentServer.GetCharacter(characterId.Value,myMerlinCharacter); merlinCharacter = myMerlinCharacter.Value; merlinCharacter.Show(0); The exception happens when calling .GetCharacter. The error is: An unhandled exception of type 'System.ArgumentException' occurred in Microsoft.Scripting.Core.dll Additional information: Could not convert argument 4294967295 for call to GetCharacter. Any ideas? -Jeff From r.worbis at cubido.at Mon Oct 13 07:48:06 2008 From: r.worbis at cubido.at (Rainer Worbis) Date: Mon, 13 Oct 2008 07:48:06 +0200 Subject: [IronPython] Debugging IronPython script code In-Reply-To: <350E7D38B6D819428718949920EC23554789335F3F@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <676F9CCC1D1D3242BE4B133746E3807E53CD65@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789335EFA@NA-EXMSG-C102.redmond.corp.microsoft.com><676F9CCC1D1D3242BE4B133746E3807E53CD68@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789335F3D@NA-EXMSG-C102.redmond.corp.microsoft.com><676F9CCC1D1D3242BE4B133746E3807E53CD69@XARA.cubido.linz> <350E7D38B6D819428718949920EC23554789335F3F@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <676F9CCC1D1D3242BE4B133746E3807E53CD70@XARA.cubido.linz> Now is't working partly - i used a app.config which apearently does not setup debugging right. What is not working is that I get only a disassembly - no source code attached. Is there something to setup before? Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Montag, 13. Oktober 2008 07:15 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code Oh, sorry, it looks like it needs to be a bool, not "true" in quotes... With that in mind this works for me: Dictionary options = new Dictionary(); options["Debug"] = true; ScriptEngine engine = Python.CreateEngine(options); ScriptSource source = engine.CreateScriptSourceFromFile("C:\\Users\\Dino\\test.py"); source.Execute(); I can put breakpoints in test.py and hit them. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 10:02 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code No - i get the Call Stack showed below [Lightweight Function] > Microsoft.Scripting.dll!Microsoft.Scripting.Runtime.OptimizedScriptCode. InvokeTarget(Microsoft.Linq.Expressions.LambdaExpression code = {Microsoft.Linq.Expressions.Expression}, Microsoft.Scripting.Runtime.Scope scope = {Microsoft.Scripting.Runtime.Scope}) + 0x1c6 bytes Microsoft.Scripting.dll!Microsoft.Scripting.ScriptCode.Run(Microsoft.Scr ipting.Runtime.Scope scope = {Microsoft.Scripting.Runtime.Scope}) + 0x42 bytes Microsoft.Scripting.dll!Microsoft.Scripting.Hosting.CompiledCode.Execute (Microsoft.Scripting.Hosting.ScriptScope scope = {Microsoft.Scripting.Hosting.ScriptScope}) + 0x77 bytes ... Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Montag, 13. Oktober 2008 06:55 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code If you right click in the call stack window and check Show External Code do you see the code then? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 9:53 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code I got as far as that - when the breakpoint is hit - VS pops up but not in some python code but in the call to Execute - the python code is marked as external code. So is there a possibility to have VS show the script code? Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Sonntag, 12. Oktober 2008 21:21 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code You can set DebugMode = true on a ScriptRuntimeSetup object. If you're using the Python class you can pass a Dictionary object to CreateRuntime with "Debug" = "true" and we'll set it for you. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 12:10 PM To: Users at lists.ironpython.com Subject: [IronPython] Debugging IronPython script code Hallo all, is there a possibility to debug IronPython code that is executed with ScriptSource.Execute or CompiledCode.Execute within VisualStudio? Setting breakpoints in the python code will can be done by System.Diagnostics.Debugger.Break() - the code breaks but I don't know how to tell VS to get into my code. Rainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamil at dworakowski.name Mon Oct 13 13:44:56 2008 From: kamil at dworakowski.name (Kamil Dworakowski) Date: Mon, 13 Oct 2008 12:44:56 +0100 Subject: [IronPython] parallel importing Message-ID: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> Importing time is such a pain that I wanted to do it in parallel on many threads. I figured that if the modules where imported in such a way that: no two threads import the same module at the same time everything would be fine. To ensure that condition, it is enough to build a dependency graph and import based on that. I did it: Resolver One start up time improved by 20% on a two-core machine. But it crashes, surprisingly on single core machines it is more often (6 crashes on 200 starts). So far I have identified two causes for crashes: 1. One thread imports a module with class B inside while another is importing a module with class C inside. If B and C are subclasses of A, it can result in IndexOutOfRangeException being raised, when, under the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is being executed. 2. Attributes on .NET modules are loaded lazily, so importing namespaces only is not enough. Attribute getting from reflected packages is not thread safe. Looks like I would have to import every class explicitly (would that be enough?). Second cause would be pretty easy to address, but I'm not so sure about the first one. Are there any more potential points of problems? I am beginning to think I was to optimistic about all of this importing on multiple cores, but if these are the only ones it could probably be still fixed. If anyone is interested the code for it is on github: http://github.com/luntain/ipy-parallel-import. -- Kamil Dworakowski Resolver Systems Ltd. From dan.eloff at gmail.com Mon Oct 13 16:12:07 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Mon, 13 Oct 2008 09:12:07 -0500 Subject: [IronPython] parallel importing In-Reply-To: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> Message-ID: <4817b6fc0810130712g7f3a153aof34073ed6c9e9a3f@mail.gmail.com> I hope that these issues can be resolved, importing time really needs to be reduced in any complex IronPython application, and this looks like the best hope yet for doing that. -Dan From dinov at microsoft.com Mon Oct 13 18:00:16 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 13 Oct 2008 09:00:16 -0700 Subject: [IronPython] parallel importing In-Reply-To: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are locking but on the wrong object in 1.x). #2 is still broken in 2.x though as well. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski Sent: Monday, October 13, 2008 4:45 AM To: users at lists.ironpython.com Subject: [IronPython] parallel importing Importing time is such a pain that I wanted to do it in parallel on many threads. I figured that if the modules where imported in such a way that: no two threads import the same module at the same time everything would be fine. To ensure that condition, it is enough to build a dependency graph and import based on that. I did it: Resolver One start up time improved by 20% on a two-core machine. But it crashes, surprisingly on single core machines it is more often (6 crashes on 200 starts). So far I have identified two causes for crashes: 1. One thread imports a module with class B inside while another is importing a module with class C inside. If B and C are subclasses of A, it can result in IndexOutOfRangeException being raised, when, under the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is being executed. 2. Attributes on .NET modules are loaded lazily, so importing namespaces only is not enough. Attribute getting from reflected packages is not thread safe. Looks like I would have to import every class explicitly (would that be enough?). Second cause would be pretty easy to address, but I'm not so sure about the first one. Are there any more potential points of problems? I am beginning to think I was to optimistic about all of this importing on multiple cores, but if these are the only ones it could probably be still fixed. If anyone is interested the code for it is on github: http://github.com/luntain/ipy-parallel-import. -- Kamil Dworakowski Resolver Systems Ltd. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Mon Oct 13 18:02:20 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 13 Oct 2008 09:02:20 -0700 Subject: [IronPython] "Merlin" tutorial not working In-Reply-To: <48F2DA70.60202@reactorzero.com> References: <48F2DA70.60202@reactorzero.com> Message-ID: <350E7D38B6D819428718949920EC23554789336001@NA-EXMSG-C102.redmond.corp.microsoft.com> The tutorial will be updated for the RC. But the code should now be: from System.Runtime.InteropServices import DispatchWrapper, UnknownWrapper c = clr.StrongBox[object](DispatchWrapper(None)) a.GetCharacter(cid.Value, c) c.Value.Show(0, reqid) c.Value.Think("IronPython Tutorial", reqid) That's more complicated then it was before (with the new COM interop support) but I'm told Merlin has a rather odd object model that you don't see very much in COM APIs. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Slutter Sent: Sunday, October 12, 2008 10:20 PM To: Discussion of IronPython Subject: [IronPython] "Merlin" tutorial not working I'm going through the IronPython tutorial and I'm at the COM interop part. I'm trying to get the Merlin example working but I can't get it past a certain part. First of all, I had to make some changes to get the example to work, as it doesn't appear the tuple/out param stuff works the same as it does in the tutorial. Here is my code: agentServer = AgentServerClass(); characterId = clr.Reference[int](); reqId = clr.Reference[int](); agentServer.Load("Merlin.acs", characterId, reqId); myMerlinCharacter = clr.Reference[object](); agentServer.GetCharacter(characterId.Value,myMerlinCharacter); merlinCharacter = myMerlinCharacter.Value; merlinCharacter.Show(0); The exception happens when calling .GetCharacter. The error is: An unhandled exception of type 'System.ArgumentException' occurred in Microsoft.Scripting.Core.dll Additional information: Could not convert argument 4294967295 for call to GetCharacter. Any ideas? -Jeff _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Mon Oct 13 18:03:14 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 13 Oct 2008 09:03:14 -0700 Subject: [IronPython] Debugging IronPython script code In-Reply-To: <676F9CCC1D1D3242BE4B133746E3807E53CD70@XARA.cubido.linz> References: <676F9CCC1D1D3242BE4B133746E3807E53CD65@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789335EFA@NA-EXMSG-C102.redmond.corp.microsoft.com><676F9CCC1D1D3242BE4B133746E3807E53CD68@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789335F3D@NA-EXMSG-C102.redmond.corp.microsoft.com><676F9CCC1D1D3242BE4B133746E3807E53CD69@XARA.cubido.linz> <350E7D38B6D819428718949920EC23554789335F3F@NA-EXMSG-C102.redmond.corp.microsoft.com> <676F9CCC1D1D3242BE4B133746E3807E53CD70@XARA.cubido.linz> Message-ID: <350E7D38B6D819428718949920EC23554789336003@NA-EXMSG-C102.redmond.corp.microsoft.com> How is the filename specified in the Create call? Is it a full path? If you just open the file in VS does VS recognize the code (e.g. can you set breakpoints)? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 10:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code Now is't working partly - i used a app.config which apearently does not setup debugging right. What is not working is that I get only a disassembly - no source code attached. Is there something to setup before? Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Montag, 13. Oktober 2008 07:15 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code Oh, sorry, it looks like it needs to be a bool, not "true" in quotes... With that in mind this works for me: Dictionary options = new Dictionary(); options["Debug"] = true; ScriptEngine engine = Python.CreateEngine(options); ScriptSource source = engine.CreateScriptSourceFromFile("C:\\Users\\Dino\\test.py"); source.Execute(); I can put breakpoints in test.py and hit them. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 10:02 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code No - i get the Call Stack showed below [Lightweight Function] > Microsoft.Scripting.dll!Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(Microsoft.Linq.Expressions.LambdaExpression code = {Microsoft.Linq.Expressions.Expression}, Microsoft.Scripting.Runtime.Scope scope = {Microsoft.Scripting.Runtime.Scope}) + 0x1c6 bytes Microsoft.Scripting.dll!Microsoft.Scripting.ScriptCode.Run(Microsoft.Scripting.Runtime.Scope scope = {Microsoft.Scripting.Runtime.Scope}) + 0x42 bytes Microsoft.Scripting.dll!Microsoft.Scripting.Hosting.CompiledCode.Execute(Microsoft.Scripting.Hosting.ScriptScope scope = {Microsoft.Scripting.Hosting.ScriptScope}) + 0x77 bytes ... Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Montag, 13. Oktober 2008 06:55 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code If you right click in the call stack window and check Show External Code do you see the code then? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 9:53 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code I got as far as that - when the breakpoint is hit - VS pops up but not in some python code but in the call to Execute - the python code is marked as external code. So is there a possibility to have VS show the script code? Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Sonntag, 12. Oktober 2008 21:21 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code You can set DebugMode = true on a ScriptRuntimeSetup object. If you're using the Python class you can pass a Dictionary object to CreateRuntime with "Debug" = "true" and we'll set it for you. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 12:10 PM To: Users at lists.ironpython.com Subject: [IronPython] Debugging IronPython script code Hallo all, is there a possibility to debug IronPython code that is executed with ScriptSource.Execute or CompiledCode.Execute within VisualStudio? Setting breakpoints in the python code will can be done by System.Diagnostics.Debugger.Break() - the code breaks but I don't know how to tell VS to get into my code. Rainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamil at dworakowski.name Mon Oct 13 18:06:31 2008 From: kamil at dworakowski.name (Kamil Dworakowski) Date: Mon, 13 Oct 2008 17:06:31 +0100 Subject: [IronPython] parallel importing In-Reply-To: <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <93fc29d60810130906x513c8070u1cda62d926710c0b@mail.gmail.com> Would that be easy to backport fix for #2 to 1.x branch? On Mon, Oct 13, 2008 at 5:00 PM, Dino Viehland wrote: > This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are locking but on the wrong object in 1.x). > > #2 is still broken in 2.x though as well. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski > Sent: Monday, October 13, 2008 4:45 AM > To: users at lists.ironpython.com > Subject: [IronPython] parallel importing > > Importing time is such a pain that I wanted to do it in parallel on > many threads. I figured that if the modules where imported in such a > way that: > > no two threads import the same module at the same time > > everything would be fine. To ensure that condition, it is enough to > build a dependency graph and import based on that. > > I did it: Resolver One start up time improved by 20% on a two-core > machine. But it crashes, surprisingly on single core machines it is > more often (6 crashes on 200 starts). > > So far I have identified two causes for crashes: > > 1. One thread imports a module with class B inside while another is > importing a module with class C inside. If B and C are subclasses of > A, it can result in IndexOutOfRangeException being raised, when, under > the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is being > executed. > > 2. Attributes on .NET modules are loaded lazily, so importing > namespaces only is not enough. Attribute getting from reflected > packages is not thread safe. Looks like I would have to import every > class explicitly (would that be enough?). > > Second cause would be pretty easy to address, but I'm not so sure > about the first one. Are there any more potential points of problems? > I am beginning to think I was to optimistic about all of this > importing on multiple cores, but if these are the only ones it could > probably be still fixed. > > If anyone is interested the code for it is on github: > http://github.com/luntain/ipy-parallel-import. > > -- > Kamil Dworakowski > Resolver Systems Ltd. > _______________________________________________ > 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 microsoft.com Mon Oct 13 18:31:03 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 13 Oct 2008 09:31:03 -0700 Subject: [IronPython] parallel importing In-Reply-To: <93fc29d60810130906x513c8070u1cda62d926710c0b@mail.gmail.com> References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> <93fc29d60810130906x513c8070u1cda62d926710c0b@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23554789336034@NA-EXMSG-C102.redmond.corp.microsoft.com> Making the code changes is easy - the hard part is really doing a new 1.x release and all of the sign off work that entails. We haven't ruled it out but we sure would like to avoid it if possible. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski Sent: Monday, October 13, 2008 9:07 AM To: Discussion of IronPython Subject: Re: [IronPython] parallel importing Would that be easy to backport fix for #2 to 1.x branch? On Mon, Oct 13, 2008 at 5:00 PM, Dino Viehland wrote: > This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are locking but on the wrong object in 1.x). > > #2 is still broken in 2.x though as well. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski > Sent: Monday, October 13, 2008 4:45 AM > To: users at lists.ironpython.com > Subject: [IronPython] parallel importing > > Importing time is such a pain that I wanted to do it in parallel on > many threads. I figured that if the modules where imported in such a > way that: > > no two threads import the same module at the same time > > everything would be fine. To ensure that condition, it is enough to > build a dependency graph and import based on that. > > I did it: Resolver One start up time improved by 20% on a two-core > machine. But it crashes, surprisingly on single core machines it is > more often (6 crashes on 200 starts). > > So far I have identified two causes for crashes: > > 1. One thread imports a module with class B inside while another is > importing a module with class C inside. If B and C are subclasses of > A, it can result in IndexOutOfRangeException being raised, when, under > the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is being > executed. > > 2. Attributes on .NET modules are loaded lazily, so importing > namespaces only is not enough. Attribute getting from reflected > packages is not thread safe. Looks like I would have to import every > class explicitly (would that be enough?). > > Second cause would be pretty easy to address, but I'm not so sure > about the first one. Are there any more potential points of problems? > I am beginning to think I was to optimistic about all of this > importing on multiple cores, but if these are the only ones it could > probably be still fixed. > > If anyone is interested the code for it is on github: > http://github.com/luntain/ipy-parallel-import. > > -- > Kamil Dworakowski > Resolver Systems Ltd. > _______________________________________________ > 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 kamil at dworakowski.name Mon Oct 13 18:41:50 2008 From: kamil at dworakowski.name (Kamil Dworakowski) Date: Mon, 13 Oct 2008 17:41:50 +0100 Subject: [IronPython] parallel importing In-Reply-To: <350E7D38B6D819428718949920EC23554789336034@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> <93fc29d60810130906x513c8070u1cda62d926710c0b@mail.gmail.com> <350E7D38B6D819428718949920EC23554789336034@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <93fc29d60810130941t4d3d5576w68ccf5ffc38aff47@mail.gmail.com> Could you provide a patch? On Mon, Oct 13, 2008 at 5:31 PM, Dino Viehland wrote: > Making the code changes is easy - the hard part is really doing a new 1.x release and all of the sign off work that entails. We haven't ruled it out but we sure would like to avoid it if possible. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski > Sent: Monday, October 13, 2008 9:07 AM > To: Discussion of IronPython > Subject: Re: [IronPython] parallel importing > > Would that be easy to backport fix for #2 to 1.x branch? > > On Mon, Oct 13, 2008 at 5:00 PM, Dino Viehland wrote: >> This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are locking but on the wrong object in 1.x). >> >> #2 is still broken in 2.x though as well. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski >> Sent: Monday, October 13, 2008 4:45 AM >> To: users at lists.ironpython.com >> Subject: [IronPython] parallel importing >> >> Importing time is such a pain that I wanted to do it in parallel on >> many threads. I figured that if the modules where imported in such a >> way that: >> >> no two threads import the same module at the same time >> >> everything would be fine. To ensure that condition, it is enough to >> build a dependency graph and import based on that. >> >> I did it: Resolver One start up time improved by 20% on a two-core >> machine. But it crashes, surprisingly on single core machines it is >> more often (6 crashes on 200 starts). >> >> So far I have identified two causes for crashes: >> >> 1. One thread imports a module with class B inside while another is >> importing a module with class C inside. If B and C are subclasses of >> A, it can result in IndexOutOfRangeException being raised, when, under >> the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is being >> executed. >> >> 2. Attributes on .NET modules are loaded lazily, so importing >> namespaces only is not enough. Attribute getting from reflected >> packages is not thread safe. Looks like I would have to import every >> class explicitly (would that be enough?). >> >> Second cause would be pretty easy to address, but I'm not so sure >> about the first one. Are there any more potential points of problems? >> I am beginning to think I was to optimistic about all of this >> importing on multiple cores, but if these are the only ones it could >> probably be still fixed. >> >> If anyone is interested the code for it is on github: >> http://github.com/luntain/ipy-parallel-import. >> >> -- >> Kamil Dworakowski >> Resolver Systems Ltd. >> _______________________________________________ >> 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 dan.eloff at gmail.com Mon Oct 13 18:52:48 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Mon, 13 Oct 2008 11:52:48 -0500 Subject: [IronPython] What's the situation on being able to accept patches? Message-ID: <4817b6fc0810130952m1ea6a2c7k436295f679399350@mail.gmail.com> I've completed the _ast module, fully implementing all classes from the CPython module for Python 2.5. In the end the only way to do it was as a patch to IronPython, partly because creating an ast from source is done through the compile() builtin, but also because someone did an optimization on GeneratorExpression that gave no public interface to the syntax info. I patched GeneratorExpression to provide the same public interface as ListComprehension, while making sure not to affect the optimization. So now you have a 2500 lines of code patch for IronPython that you cannot yet accept. What's the situation here? How long is this likely to remain a problem (with the answer so dependent on lawyers I'm not optimisitc) It's way too late for this to end up in 2.0, but I was hoping for 2.1. And if I supply a python doctest with the patch is that even useful to you guys in your testing harness? -Dan From vernondcole at gmail.com Mon Oct 13 18:57:58 2008 From: vernondcole at gmail.com (Vernon Cole) Date: Mon, 13 Oct 2008 10:57:58 -0600 Subject: [IronPython] parallel importing In-Reply-To: <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: Help me out here. I have seen many references to schemes to optimize import speeds on Iron Python. Isn't this an attempt to make up for the snail-like startup speeds suffered by *all* .net applications? It seems to me that when Iron Python finally starts running, it imports and performs very well. The slowdown is in getting the .net engine started. Try comparing startup times for "Hello World" in C Python and Iron. It is my experience that I can identify .net programs in general by the fact that I have double-clicked its desktop icon three times (thinking I had missed it somehow) before the first instance displays its splash screen, and then the next two display an "already running" dialog. Any chance of getting the .net people to help out with this? -- Vernon Cole On Mon, Oct 13, 2008 at 10:00 AM, Dino Viehland wrote: > This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are > locking but on the wrong object in 1.x). > > #2 is still broken in 2.x though as well. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski > Sent: Monday, October 13, 2008 4:45 AM > To: users at lists.ironpython.com > Subject: [IronPython] parallel importing > > Importing time is such a pain that I wanted to do it in parallel on > many threads. I figured that if the modules where imported in such a > way that: > > no two threads import the same module at the same time > > everything would be fine. To ensure that condition, it is enough to > build a dependency graph and import based on that. > > I did it: Resolver One start up time improved by 20% on a two-core > machine. But it crashes, surprisingly on single core machines it is > more often (6 crashes on 200 starts). > > So far I have identified two causes for crashes: > > 1. One thread imports a module with class B inside while another is > importing a module with class C inside. If B and C are subclasses of > A, it can result in IndexOutOfRangeException being raised, when, under > the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is being > executed. > > 2. Attributes on .NET modules are loaded lazily, so importing > namespaces only is not enough. Attribute getting from reflected > packages is not thread safe. Looks like I would have to import every > class explicitly (would that be enough?). > > Second cause would be pretty easy to address, but I'm not so sure > about the first one. Are there any more potential points of problems? > I am beginning to think I was to optimistic about all of this > importing on multiple cores, but if these are the only ones it could > probably be still fixed. > > If anyone is interested the code for it is on github: > http://github.com/luntain/ipy-parallel-import. > > -- > Kamil Dworakowski > Resolver Systems Ltd. > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.eloff at gmail.com Mon Oct 13 19:10:52 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Mon, 13 Oct 2008 12:10:52 -0500 Subject: [IronPython] parallel importing In-Reply-To: References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <4817b6fc0810131010g269d7f93obd71bcda29db4408@mail.gmail.com> On Mon, Oct 13, 2008 at 11:57 AM, Vernon Cole wrote: > Help me out here. I have seen many references to schemes to optimize import > speeds on Iron Python. Isn't this an attempt to make up for the snail-like > startup speeds suffered by all .net applications? .NET has a substantial startup time, as does IronPython, and for small applications, that will rule the day. However, for applications that import in excess of 100 python files, that startup time starts to look small. For me importing (starting timing only once IronPython has started) takes a full 10 seconds on a 3.6GHz Core2. On a 2Ghz Pentium 4, this time triples. I suspect the resolver guys have a similar story to tell. -Dan From curt at hagenlocher.org Mon Oct 13 19:11:03 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 13 Oct 2008 10:11:03 -0700 Subject: [IronPython] parallel importing In-Reply-To: References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: The" .NET people" might say they already have an answer which involves precompiling the IL with NGEN. And in fact, using DLR precompilation and NGEN with IronPython results in some pretty nice performance improvements. But using IronPython directly against .py files incurs several expenses that aren't part of normal .NET startup. We have to parse the .py file, build DLR-level expression trees from the language tree and build IL from the expression tree. Only then are we at the point where a C# starts, and can JIT the IL. It's worth noting that CPython has to do similar work when it first loads a .py file. It, too, has to parse into a tree structure and generate byte codes for the tree. And even though the CPython byte code is at a higher level than the IL generated by the DLR, CPython still has a performance issue -- which is addressed by storing the byte codes as a .pyc file. I'm hoping that over the next year, we'll come up with a convention (like .pyc) that allows subsequent runs of a program to benefit from the work done in previous runs -- without having to go through the manual step of DLR precompilation. On Mon, Oct 13, 2008 at 9:57 AM, Vernon Cole wrote: > Help me out here. I have seen many references to schemes to optimize > import speeds on Iron Python. Isn't this an attempt to make up for the > snail-like startup speeds suffered by *all* .net applications? It seems to > me that when Iron Python finally starts running, it imports and performs > very well. The slowdown is in getting the .net engine started. Try comparing > startup times for "Hello World" in C Python and Iron. > It is my experience that I can identify .net programs in general by the > fact that I have double-clicked its desktop icon three times (thinking I had > missed it somehow) before the first instance displays its splash screen, and > then the next two display an "already running" dialog. > Any chance of getting the .net people to help out with this? > -- > Vernon Cole > > > On Mon, Oct 13, 2008 at 10:00 AM, Dino Viehland wrote: > >> This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are >> locking but on the wrong object in 1.x). >> >> #2 is still broken in 2.x though as well. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto: >> users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski >> Sent: Monday, October 13, 2008 4:45 AM >> To: users at lists.ironpython.com >> Subject: [IronPython] parallel importing >> >> Importing time is such a pain that I wanted to do it in parallel on >> many threads. I figured that if the modules where imported in such a >> way that: >> >> no two threads import the same module at the same time >> >> everything would be fine. To ensure that condition, it is enough to >> build a dependency graph and import based on that. >> >> I did it: Resolver One start up time improved by 20% on a two-core >> machine. But it crashes, surprisingly on single core machines it is >> more often (6 crashes on 200 starts). >> >> So far I have identified two causes for crashes: >> >> 1. One thread imports a module with class B inside while another is >> importing a module with class C inside. If B and C are subclasses of >> A, it can result in IndexOutOfRangeException being raised, when, under >> the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is being >> executed. >> >> 2. Attributes on .NET modules are loaded lazily, so importing >> namespaces only is not enough. Attribute getting from reflected >> packages is not thread safe. Looks like I would have to import every >> class explicitly (would that be enough?). >> >> Second cause would be pretty easy to address, but I'm not so sure >> about the first one. Are there any more potential points of problems? >> I am beginning to think I was to optimistic about all of this >> importing on multiple cores, but if these are the only ones it could >> probably be still fixed. >> >> If anyone is interested the code for it is on github: >> http://github.com/luntain/ipy-parallel-import. >> >> -- >> Kamil Dworakowski >> Resolver Systems Ltd. >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Oct 13 19:15:21 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 13 Oct 2008 18:15:21 +0100 Subject: [IronPython] What's the situation on being able to accept patches? In-Reply-To: <4817b6fc0810130952m1ea6a2c7k436295f679399350@mail.gmail.com> References: <4817b6fc0810130952m1ea6a2c7k436295f679399350@mail.gmail.com> Message-ID: <48F38229.907@voidspace.org.uk> Dan Eloff wrote: > I've completed the _ast module, fully implementing all classes from > the CPython module for Python 2.5. In the end the only way to do it > was as a patch to IronPython, partly because creating an ast from > source is done through the compile() builtin, but also because someone > did an optimization on GeneratorExpression that gave no public > interface to the syntax info. I patched GeneratorExpression to provide > the same public interface as ListComprehension, while making sure not > to affect the optimization. So now you have a 2500 lines of code patch > for IronPython that you cannot yet accept. What's the situation here? > How long is this likely to remain a problem (with the answer so > dependent on lawyers I'm not optimisitc) > > It's way too late for this to end up in 2.0, but I was hoping for 2.1. > > And if I supply a python doctest with the patch is that even useful to > you guys in your testing harness? > > The IronPython guys don't yet have permission to accept patches. Permission to contribute to the modules will come before contributions to the core IronPython - and we are unlikely to be ever able to contribute to the DLR. However - FePy will gladly accept your patches... I expect Seo will even add you as a commiter as the current state of FePy is that it is at 2.0a5 and badly needs an update. :-) If 2.1 has significant benefits we could even release 2.1 before 2.0 is officially out. :-) Michael > -Dan > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://wwww.theotherdelia.co.uk/ From fuzzyman at voidspace.org.uk Mon Oct 13 19:16:49 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 13 Oct 2008 18:16:49 +0100 Subject: [IronPython] parallel importing In-Reply-To: References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <48F38281.1050902@voidspace.org.uk> Curt Hagenlocher wrote: > The" .NET people" might say they already have an answer which involves > precompiling the IL with NGEN. And in fact, using DLR precompilation > and NGEN with IronPython results in some pretty nice performance > improvements. > > But using IronPython directly against .py files incurs several > expenses that aren't part of normal .NET startup. We have to parse > the .py file, build DLR-level expression trees from the language tree > and build IL from the expression tree. Only then are we at the point > where a C# starts, and can JIT the IL. > > It's worth noting that CPython has to do similar work when it first > loads a .py file. It, too, has to parse into a tree structure and > generate byte codes for the tree. And even though the CPython byte > code is at a higher level than the IL generated by the DLR, CPython > still has a performance issue -- which is addressed by storing the > byte codes as a .pyc file. The difference is still orders of magnitude smaller though... We're looking forward to moving to precompiled binaries with IronPython 2 at Resolver Systems - but there we will still have situations where we need to import from py files. Michael > > I'm hoping that over the next year, we'll come up with a convention > (like .pyc) that allows subsequent runs of a program to benefit from > the work done in previous runs -- without having to go through the > manual step of DLR precompilation. > > On Mon, Oct 13, 2008 at 9:57 AM, Vernon Cole > wrote: > > Help me out here. I have seen many references to schemes to > optimize import speeds on Iron Python. Isn't this an attempt to > make up for the snail-like startup speeds suffered by *all* .net > applications? It seems to me that when Iron Python finally starts > running, it imports and performs very well. The slowdown is in > getting the .net engine started. Try comparing startup times for > "Hello World" in C Python and Iron. > It is my experience that I can identify .net programs in > general by the fact that I have double-clicked its desktop icon > three times (thinking I had missed it somehow) before the first > instance displays its splash screen, and then the next two display > an "already running" dialog. > Any chance of getting the .net people to help out with this? > -- > Vernon Cole > > > On Mon, Oct 13, 2008 at 10:00 AM, Dino Viehland > > wrote: > > This is all still on 1.x, right? It looks like #1 is fixed in > 2.0 (we are locking but on the wrong object in 1.x). > > #2 is still broken in 2.x though as well. > > -----Original Message----- > From: users-bounces at lists.ironpython.com > > [mailto:users-bounces at lists.ironpython.com > ] On Behalf Of > Kamil Dworakowski > Sent: Monday, October 13, 2008 4:45 AM > To: users at lists.ironpython.com > Subject: [IronPython] parallel importing > > Importing time is such a pain that I wanted to do it in > parallel on > many threads. I figured that if the modules where imported in > such a > way that: > > no two threads import the same module at the same time > > everything would be fine. To ensure that condition, it is > enough to > build a dependency graph and import based on that. > > I did it: Resolver One start up time improved by 20% on a two-core > machine. But it crashes, surprisingly on single core machines > it is > more often (6 crashes on 200 starts). > > So far I have identified two causes for crashes: > > 1. One thread imports a module with class B inside while > another is > importing a module with class C inside. If B and C are > subclasses of > A, it can result in IndexOutOfRangeException being raised, > when, under > the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is > being > executed. > > 2. Attributes on .NET modules are loaded lazily, so importing > namespaces only is not enough. Attribute getting from reflected > packages is not thread safe. Looks like I would have to import > every > class explicitly (would that be enough?). > > Second cause would be pretty easy to address, but I'm not so sure > about the first one. Are there any more potential points of > problems? > I am beginning to think I was to optimistic about all of this > importing on multiple cores, but if these are the only ones it > could > probably be still fixed. > > If anyone is interested the code for it is on github: > http://github.com/luntain/ipy-parallel-import. > > -- > Kamil Dworakowski > Resolver Systems Ltd. > _______________________________________________ > 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 > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://wwww.theotherdelia.co.uk/ From dinov at microsoft.com Mon Oct 13 20:19:57 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 13 Oct 2008 11:19:57 -0700 Subject: [IronPython] parallel importing In-Reply-To: References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <350E7D38B6D819428718949920EC235547893360E6@NA-EXMSG-C102.redmond.corp.microsoft.com> Speeding up code gen is certainly an issue that has been brought up internally - but I don't think there's anything concrete there yet. Anyways that'll require a .NET framework update so it's a good long term solution but not so good for the short term. The CLR's solution to this in the past has been ngen hence the reason we're leveraging that for the short term. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Vernon Cole Sent: Monday, October 13, 2008 9:58 AM To: Discussion of IronPython Subject: Re: [IronPython] parallel importing Help me out here. I have seen many references to schemes to optimize import speeds on Iron Python. Isn't this an attempt to make up for the snail-like startup speeds suffered by all .net applications? It seems to me that when Iron Python finally starts running, it imports and performs very well. The slowdown is in getting the .net engine started. Try comparing startup times for "Hello World" in C Python and Iron. It is my experience that I can identify .net programs in general by the fact that I have double-clicked its desktop icon three times (thinking I had missed it somehow) before the first instance displays its splash screen, and then the next two display an "already running" dialog. Any chance of getting the .net people to help out with this? -- Vernon Cole On Mon, Oct 13, 2008 at 10:00 AM, Dino Viehland > wrote: This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are locking but on the wrong object in 1.x). #2 is still broken in 2.x though as well. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski Sent: Monday, October 13, 2008 4:45 AM To: users at lists.ironpython.com Subject: [IronPython] parallel importing Importing time is such a pain that I wanted to do it in parallel on many threads. I figured that if the modules where imported in such a way that: no two threads import the same module at the same time everything would be fine. To ensure that condition, it is enough to build a dependency graph and import based on that. I did it: Resolver One start up time improved by 20% on a two-core machine. But it crashes, surprisingly on single core machines it is more often (6 crashes on 200 starts). So far I have identified two causes for crashes: 1. One thread imports a module with class B inside while another is importing a module with class C inside. If B and C are subclasses of A, it can result in IndexOutOfRangeException being raised, when, under the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is being executed. 2. Attributes on .NET modules are loaded lazily, so importing namespaces only is not enough. Attribute getting from reflected packages is not thread safe. Looks like I would have to import every class explicitly (would that be enough?). Second cause would be pretty easy to address, but I'm not so sure about the first one. Are there any more potential points of problems? I am beginning to think I was to optimistic about all of this importing on multiple cores, but if these are the only ones it could probably be still fixed. If anyone is interested the code for it is on github: http://github.com/luntain/ipy-parallel-import. -- Kamil Dworakowski Resolver Systems Ltd. _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Oct 13 20:20:28 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 13 Oct 2008 11:20:28 -0700 Subject: [IronPython] parallel importing In-Reply-To: <93fc29d60810130941t4d3d5576w68ccf5ffc38aff47@mail.gmail.com> References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> <93fc29d60810130906x513c8070u1cda62d926710c0b@mail.gmail.com> <350E7D38B6D819428718949920EC23554789336034@NA-EXMSG-C102.redmond.corp.microsoft.com> <93fc29d60810130941t4d3d5576w68ccf5ffc38aff47@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC235547893360E8@NA-EXMSG-C102.redmond.corp.microsoft.com> Yep, give me a bit of time - I'll try and get it later today or tomorrow... -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski Sent: Monday, October 13, 2008 9:42 AM To: Discussion of IronPython Subject: Re: [IronPython] parallel importing Could you provide a patch? On Mon, Oct 13, 2008 at 5:31 PM, Dino Viehland wrote: > Making the code changes is easy - the hard part is really doing a new 1.x release and all of the sign off work that entails. We haven't ruled it out but we sure would like to avoid it if possible. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski > Sent: Monday, October 13, 2008 9:07 AM > To: Discussion of IronPython > Subject: Re: [IronPython] parallel importing > > Would that be easy to backport fix for #2 to 1.x branch? > > On Mon, Oct 13, 2008 at 5:00 PM, Dino Viehland wrote: >> This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are locking but on the wrong object in 1.x). >> >> #2 is still broken in 2.x though as well. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski >> Sent: Monday, October 13, 2008 4:45 AM >> To: users at lists.ironpython.com >> Subject: [IronPython] parallel importing >> >> Importing time is such a pain that I wanted to do it in parallel on >> many threads. I figured that if the modules where imported in such a >> way that: >> >> no two threads import the same module at the same time >> >> everything would be fine. To ensure that condition, it is enough to >> build a dependency graph and import based on that. >> >> I did it: Resolver One start up time improved by 20% on a two-core >> machine. But it crashes, surprisingly on single core machines it is >> more often (6 crashes on 200 starts). >> >> So far I have identified two causes for crashes: >> >> 1. One thread imports a module with class B inside while another is >> importing a module with class C inside. If B and C are subclasses of >> A, it can result in IndexOutOfRangeException being raised, when, under >> the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is being >> executed. >> >> 2. Attributes on .NET modules are loaded lazily, so importing >> namespaces only is not enough. Attribute getting from reflected >> packages is not thread safe. Looks like I would have to import every >> class explicitly (would that be enough?). >> >> Second cause would be pretty easy to address, but I'm not so sure >> about the first one. Are there any more potential points of problems? >> I am beginning to think I was to optimistic about all of this >> importing on multiple cores, but if these are the only ones it could >> probably be still fixed. >> >> If anyone is interested the code for it is on github: >> http://github.com/luntain/ipy-parallel-import. >> >> -- >> Kamil Dworakowski >> Resolver Systems Ltd. >> _______________________________________________ >> 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 dan.eloff at gmail.com Mon Oct 13 20:21:43 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Mon, 13 Oct 2008 13:21:43 -0500 Subject: [IronPython] What's the situation on being able to accept patches? In-Reply-To: <48F38229.907@voidspace.org.uk> References: <4817b6fc0810130952m1ea6a2c7k436295f679399350@mail.gmail.com> <48F38229.907@voidspace.org.uk> Message-ID: <4817b6fc0810131121m3d46b1cdt3de5d85b04043e4b@mail.gmail.com> > The IronPython guys don't yet have permission to accept patches. Permission > to contribute to the modules will come before contributions to the core > IronPython - and we are unlikely to be ever able to contribute to the DLR. I guess the DLR is moving into the CLR so I can see why Microsoft would take that stance. I can very easily move everything into IronPython.Modules, (it belongs there anyway) the patches to compile and GeneratorExpression are so simple that the IronPython team can rewrite them in under 20 minutes using my code as a reference. As Michael points out, would that make it easier? -Dan From ronnie.maor at gmail.com Mon Oct 13 22:57:13 2008 From: ronnie.maor at gmail.com (Ronnie Maor) Date: Mon, 13 Oct 2008 22:57:13 +0200 Subject: [IronPython] Problem with random module in IPY 1.1.1 In-Reply-To: <003001c92c4c$baad3560$3007a020$@com> References: <003001c92c4c$baad3560$3007a020$@com> Message-ID: <2fd6b9d0810131357y79bd656fyf93a3d23cf0b9e20@mail.gmail.com> problem was caused by calling random from several threads without locking. it reproduces more easily in IPy than in CPython because of the GIL, but it's documented as not thread safe for CPython too. On Sun, Oct 12, 2008 at 11:27 AM, Asaf Kleinbort wrote: > Hi, > > We have encountered two strange errors in the 'random' module: > > 1. At some point the random method 'getrandbits(63)' started (and > kept) returning 0 ? until we restarted the application. > > 2. The random method 'shuffle' when applied on a list kept returning > the same ordered list. Again ? restarting the application solved the problem > > An interesting remark is that issue #1 happened to us today in two > different applications, around the same time. > > Any ideas? > > Thanks, > > Asaf > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Oct 13 22:50:52 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 13 Oct 2008 13:50:52 -0700 Subject: [IronPython] What's the situation on being able to accept patches? In-Reply-To: <4817b6fc0810131121m3d46b1cdt3de5d85b04043e4b@mail.gmail.com> References: <4817b6fc0810130952m1ea6a2c7k436295f679399350@mail.gmail.com> <48F38229.907@voidspace.org.uk> <4817b6fc0810131121m3d46b1cdt3de5d85b04043e4b@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23554FF5D2E61E@NA-EXMSG-C102.redmond.corp.microsoft.com> Harry's currently pushing on the lawyers to get this through although he's been a little distracted by PDC. I certainly hope we can take this back in 2.1 but I can't promise anything. The good news is that a Michael points out this is the exact sort of thing we want to take back first. In RC1 you'll be able to put PythonModuleAttribute in your own assembly, add the assembly to a DLLs directory below ipy, and we'll pick it up as a normal Python module. Then later we can move it into IronPython.Modules.dll when we get the ability to take the contributions. In the mean time I would assume you just need the FunctionDefinition and Expression exposed off of GeneratorExpression. Is that right or is it something else? I should be able to do that for RC1. For compile I think you could back-patch the built-in modules. You can add a [SpecialName] void PerformModuleReload(PythonContext, IAttributeCollection) method to your module to know when it gets imported/reloaded and you can then patch builtin.compile with a version of your own which calls the built-in version. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff Sent: Monday, October 13, 2008 11:22 AM To: Discussion of IronPython Subject: Re: [IronPython] What's the situation on being able to accept patches? > The IronPython guys don't yet have permission to accept patches. Permission > to contribute to the modules will come before contributions to the core > IronPython - and we are unlikely to be ever able to contribute to the DLR. I guess the DLR is moving into the CLR so I can see why Microsoft would take that stance. I can very easily move everything into IronPython.Modules, (it belongs there anyway) the patches to compile and GeneratorExpression are so simple that the IronPython team can rewrite them in under 20 minutes using my code as a reference. As Michael points out, would that make it easier? -Dan _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Mon Oct 13 23:29:42 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 13 Oct 2008 14:29:42 -0700 Subject: [IronPython] Problem with random module in IPY 1.1.1 In-Reply-To: <2fd6b9d0810131357y79bd656fyf93a3d23cf0b9e20@mail.gmail.com> References: <003001c92c4c$baad3560$3007a020$@com> <2fd6b9d0810131357y79bd656fyf93a3d23cf0b9e20@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23554FF5D2E6A3@NA-EXMSG-C102.redmond.corp.microsoft.com> Wow, I'm surprised it's documented as being thread unsafe in CPython, but it's good to know. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ronnie Maor Sent: Monday, October 13, 2008 1:57 PM To: Discussion of IronPython Subject: Re: [IronPython] Problem with random module in IPY 1.1.1 problem was caused by calling random from several threads without locking. it reproduces more easily in IPy than in CPython because of the GIL, but it's documented as not thread safe for CPython too. On Sun, Oct 12, 2008 at 11:27 AM, Asaf Kleinbort > wrote: Hi, We have encountered two strange errors in the 'random' module: 1. At some point the random method 'getrandbits(63)' started (and kept) returning 0 - until we restarted the application. 2. The random method 'shuffle' when applied on a list kept returning the same ordered list. Again - restarting the application solved the problem An interesting remark is that issue #1 happened to us today in two different applications, around the same time. Any ideas? Thanks, Asaf _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.eloff at gmail.com Tue Oct 14 00:49:07 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Mon, 13 Oct 2008 17:49:07 -0500 Subject: [IronPython] What's the situation on being able to accept patches? In-Reply-To: <350E7D38B6D819428718949920EC23554FF5D2E61E@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <4817b6fc0810130952m1ea6a2c7k436295f679399350@mail.gmail.com> <48F38229.907@voidspace.org.uk> <4817b6fc0810131121m3d46b1cdt3de5d85b04043e4b@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF5D2E61E@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <4817b6fc0810131549h1d5e9cf8h45c2e6819c78292f@mail.gmail.com> On Mon, Oct 13, 2008 at 3:50 PM, Dino Viehland wrote: > In the mean time I would assume you just need the FunctionDefinition and Expression exposed off of GeneratorExpression. Is that right or is it something else? I should be able to do that for RC1. > That's initially what I did, but exposing an optimization in a public interface did not sit well with me. I thought ideally it should offer the same public interface as a ListComprehension node, so I implemented that. Benefit is it provides a consistent interface to users of the IronPython ast (me included). I'm attaching the modified .cs file here, you can use it as a reference if you decide to take that approach. > For compile I think you could back-patch the built-in modules. You can add a [SpecialName] void PerformModuleReload(PythonContext, IAttributeCollection) method to your module to know when it gets imported/reloaded and you can then patch builtin.compile with a version of your own which calls the built-in version. I like the sound of that. It could be possible for people to use _ast with an official IronPython 2.0 distribution. I've seen the PerformModuleReload around in the source code, but I'm not clear on how to replace the builtin compile from there. If you could give me a brief example I can fix my code to work that way. Thanks, -Dan -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: GeneratorExpression.cs URL: From dinov at microsoft.com Tue Oct 14 01:05:44 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 13 Oct 2008 16:05:44 -0700 Subject: [IronPython] What's the situation on being able to accept patches? In-Reply-To: <4817b6fc0810131549h1d5e9cf8h45c2e6819c78292f@mail.gmail.com> References: <4817b6fc0810130952m1ea6a2c7k436295f679399350@mail.gmail.com> <48F38229.907@voidspace.org.uk> <4817b6fc0810131121m3d46b1cdt3de5d85b04043e4b@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF5D2E61E@NA-EXMSG-C102.redmond.corp.microsoft.com> <4817b6fc0810131549h1d5e9cf8h45c2e6819c78292f@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23554FF5D2E77B@NA-EXMSG-C102.redmond.corp.microsoft.com> I think it should look something like this: delegate object ParamsDelegate(params object[] args); [SpecialName] public static void PerformModuleReload(PythonContext/*!*/ context, IAttributesCollection/*!*/ dict) { object prev; if(context.BuiltinModuleInstance.TryGetName(SymbolTable.StringToId("compile"), out prev)) { context.BuiltinModuleInstance.SetName(SymbolTable.StringToId("compile"), new ParamsDelegate(new CompilerHelper(prev, context).compile)); } } class CompileHelper { private object _prev; private PythonContext _context; object compile(params object[] args) { if(someCheck) { return BuildYourAst(); } return _context.Call(new CodeContext(new Scope(), _context), args); } } That's a little more complicated than it needs to be but that's due to too many internal APIs. For example there's no good way for you to make a builtin function so I'm just exposing a callable delegate directly instead. I'm just going to expose the existing items we have on GeneratorExpression for the time being. That'll unblock you and it keeps the change small for 2.0. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff Sent: Monday, October 13, 2008 3:49 PM To: Discussion of IronPython Subject: Re: [IronPython] What's the situation on being able to accept patches? On Mon, Oct 13, 2008 at 3:50 PM, Dino Viehland wrote: > In the mean time I would assume you just need the FunctionDefinition and Expression exposed off of GeneratorExpression. Is that right or is it something else? I should be able to do that for RC1. > That's initially what I did, but exposing an optimization in a public interface did not sit well with me. I thought ideally it should offer the same public interface as a ListComprehension node, so I implemented that. Benefit is it provides a consistent interface to users of the IronPython ast (me included). I'm attaching the modified .cs file here, you can use it as a reference if you decide to take that approach. > For compile I think you could back-patch the built-in modules. You can add a [SpecialName] void PerformModuleReload(PythonContext, IAttributeCollection) method to your module to know when it gets imported/reloaded and you can then patch builtin.compile with a version of your own which calls the built-in version. I like the sound of that. It could be possible for people to use _ast with an official IronPython 2.0 distribution. I've seen the PerformModuleReload around in the source code, but I'm not clear on how to replace the builtin compile from there. If you could give me a brief example I can fix my code to work that way. Thanks, -Dan From dinov at microsoft.com Tue Oct 14 01:10:43 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 13 Oct 2008 16:10:43 -0700 Subject: [IronPython] parallel importing In-Reply-To: <93fc29d60810130941t4d3d5576w68ccf5ffc38aff47@mail.gmail.com> References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> <93fc29d60810130906x513c8070u1cda62d926710c0b@mail.gmail.com> <350E7D38B6D819428718949920EC23554789336034@NA-EXMSG-C102.redmond.corp.microsoft.com> <93fc29d60810130941t4d3d5576w68ccf5ffc38aff47@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23554FF5D2E786@NA-EXMSG-C102.redmond.corp.microsoft.com> Attached is a unified diff of the changes (supposedly equivalent to diff -u). Let me know if some other diff format would be better. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski Sent: Monday, October 13, 2008 9:42 AM To: Discussion of IronPython Subject: Re: [IronPython] parallel importing Could you provide a patch? On Mon, Oct 13, 2008 at 5:31 PM, Dino Viehland wrote: > Making the code changes is easy - the hard part is really doing a new 1.x release and all of the sign off work that entails. We haven't ruled it out but we sure would like to avoid it if possible. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski > Sent: Monday, October 13, 2008 9:07 AM > To: Discussion of IronPython > Subject: Re: [IronPython] parallel importing > > Would that be easy to backport fix for #2 to 1.x branch? > > On Mon, Oct 13, 2008 at 5:00 PM, Dino Viehland wrote: >> This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are locking but on the wrong object in 1.x). >> >> #2 is still broken in 2.x though as well. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski >> Sent: Monday, October 13, 2008 4:45 AM >> To: users at lists.ironpython.com >> Subject: [IronPython] parallel importing >> >> Importing time is such a pain that I wanted to do it in parallel on >> many threads. I figured that if the modules where imported in such a >> way that: >> >> no two threads import the same module at the same time >> >> everything would be fine. To ensure that condition, it is enough to >> build a dependency graph and import based on that. >> >> I did it: Resolver One start up time improved by 20% on a two-core >> machine. But it crashes, surprisingly on single core machines it is >> more often (6 crashes on 200 starts). >> >> So far I have identified two causes for crashes: >> >> 1. One thread imports a module with class B inside while another is >> importing a module with class C inside. If B and C are subclasses of >> A, it can result in IndexOutOfRangeException being raised, when, under >> the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is being >> executed. >> >> 2. Attributes on .NET modules are loaded lazily, so importing >> namespaces only is not enough. Attribute getting from reflected >> packages is not thread safe. Looks like I would have to import every >> class explicitly (would that be enough?). >> >> Second cause would be pretty easy to address, but I'm not so sure >> about the first one. Are there any more potential points of problems? >> I am beginning to think I was to optimistic about all of this >> importing on multiple cores, but if these are the only ones it could >> probably be still fixed. >> >> If anyone is interested the code for it is on github: >> http://github.com/luntain/ipy-parallel-import. >> >> -- >> Kamil Dworakowski >> Resolver Systems Ltd. >> _______________________________________________ >> 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 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: From curt at hagenlocher.org Tue Oct 14 01:12:53 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 13 Oct 2008 16:12:53 -0700 Subject: [IronPython] Problem with random module in IPY 1.1.1 In-Reply-To: <2fd6b9d0810131357y79bd656fyf93a3d23cf0b9e20@mail.gmail.com> References: <003001c92c4c$baad3560$3007a020$@com> <2fd6b9d0810131357y79bd656fyf93a3d23cf0b9e20@mail.gmail.com> Message-ID: The underlying problem in the Python code is likely to be because of the behavior of the "random" function in the C library. And for us, this is actually a problem in the BCL. Someone just posted the exact same behavior to an internal mailing list, but from a C# program. They wrote: "I just encountered this behavior of Random.Next(): if I create one Random object and call Next() from one thread (doesn't need to be the main thread), everything works fine. However, if I create one Random object and call Next() on it from two or more threads, after a while it will start to return 0 all the time, and its internal SeedArray becomes all 0." The Python library contains a comment which reads "The random() method is implemented in C, executes in a single Python step, and is, therefore, threadsafe" so arguably, this is a bug in the _random module of IronPython. Please report it to CodePlex. On Mon, Oct 13, 2008 at 1:57 PM, Ronnie Maor wrote: > problem was caused by calling random from several threads without locking. > it reproduces more easily in IPy than in CPython because of the GIL, but > it's documented as not thread safe for CPython too. > > On Sun, Oct 12, 2008 at 11:27 AM, Asaf Kleinbort wrote: > >> Hi, >> >> We have encountered two strange errors in the 'random' module: >> >> 1. At some point the random method 'getrandbits(63)' started (and >> kept) returning 0 ? until we restarted the application. >> >> 2. The random method 'shuffle' when applied on a list kept >> returning the same ordered list. Again ? restarting the application solved >> the problem >> >> An interesting remark is that issue #1 happened to us today in two >> different applications, around the same time. >> >> Any ideas? >> >> Thanks, >> >> Asaf >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronnie.maor at gmail.com Tue Oct 14 01:37:50 2008 From: ronnie.maor at gmail.com (Ronnie Maor) Date: Tue, 14 Oct 2008 01:37:50 +0200 Subject: [IronPython] Problem with random module in IPY 1.1.1 In-Reply-To: References: <003001c92c4c$baad3560$3007a020$@com> <2fd6b9d0810131357y79bd656fyf93a3d23cf0b9e20@mail.gmail.com> Message-ID: <2fd6b9d0810131637i745e2b31h1879b1993fc19388@mail.gmail.com> I was using David Beazley's reference and saw a comment that says it isn't thread safe, but I must admit that my repro doesn't work for CPython. anyway, opened codeplex item: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=18926 On Tue, Oct 14, 2008 at 1:12 AM, Curt Hagenlocher wrote: > The underlying problem in the Python code is likely to be because of the > behavior of the "random" function in the C library. And for us, this is > actually a problem in the BCL. Someone just posted the exact same behavior > to an internal mailing list, but from a C# program. They wrote: "I just > encountered this behavior of Random.Next(): if I create one Random object > and call Next() from one thread (doesn't need to be the main thread), > everything works fine. However, if I create one Random object and call > Next() on it from two or more threads, after a while it will start to return > 0 all the time, and its internal SeedArray becomes all 0." > > The Python library contains a comment which reads "The random() method is > implemented in C, executes in a single Python step, and is, therefore, > threadsafe" so arguably, this is a bug in the _random module of IronPython. > Please report it to CodePlex. > > On Mon, Oct 13, 2008 at 1:57 PM, Ronnie Maor wrote: > >> problem was caused by calling random from several threads without locking. >> it reproduces more easily in IPy than in CPython because of the GIL, but >> it's documented as not thread safe for CPython too. >> >> On Sun, Oct 12, 2008 at 11:27 AM, Asaf Kleinbort wrote: >> >>> Hi, >>> >>> We have encountered two strange errors in the 'random' module: >>> >>> 1. At some point the random method 'getrandbits(63)' started (and >>> kept) returning 0 ? until we restarted the application. >>> >>> 2. The random method 'shuffle' when applied on a list kept >>> returning the same ordered list. Again ? restarting the application solved >>> the problem >>> >>> An interesting remark is that issue #1 happened to us today in two >>> different applications, around the same time. >>> >>> Any ideas? >>> >>> Thanks, >>> >>> Asaf >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangym at gmail.com Tue Oct 14 02:52:26 2008 From: wangym at gmail.com (Yongming) Date: Mon, 13 Oct 2008 17:52:26 -0700 (PDT) Subject: [IronPython] Debug IP script embedded in c# application In-Reply-To: <350E7D38B6D819428718949920EC23554789335EF5@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <1926d750-8f20-43f1-b552-082e0c96a925@v16g2000prc.googlegroups.com> <350E7D38B6D819428718949920EC23554789335EF5@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <4bfe24c5-e50f-4f23-8bb3-0e03852ff31e@z6g2000pre.googlegroups.com> Thanks, The breakpoints works now after set debugMode="true". But I can't watch the variable in the watch window. When I try to watch a variable a after it was assigned. a = 10 "The name 'a' does not exist in the current context" It's the same for those variable set into the scope from my main application. On Oct 12, 11:49?pm, Dino Viehland wrote: > Did you set DebugMore = true on a ScriptRuntimeSetup object? ?If you're using the Python class you can pass a Dictionary object to CreateRuntime with "Debug" = "true" and we'll set it for you. > > > > -----Original Message----- > From: users-boun... at lists.ironpython.com [mailto:users-boun... at lists.ironpython.com] On Behalf Of Yongming > Sent: Sunday, October 12, 2008 5:50 AM > To: us... at lists.ironpython.com > Subject: [IronPython] Debug IP script embedded in c# application > > Hello, I tried to extend my c# application with IronPython 2.0 > scripts. > So an IDE was wanted to debug the scripts. > I tried the ways Michael mentioned here, but it didn't work for me.http://tech-michael.blogspot.com/2008/07/i-was-charged-by-company-i-w... > Did anyone tried his way, did it worked with IP 2.0? > Or any other tools I can use to debug my scripts? > _______________________________________________ > Users mailing list > Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Us... at lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/users-ironpython.com- Hide quoted text - > > - Show quoted text - From r.worbis at cubido.at Tue Oct 14 07:04:06 2008 From: r.worbis at cubido.at (Rainer Worbis) Date: Tue, 14 Oct 2008 07:04:06 +0200 Subject: [IronPython] Debugging IronPython script code In-Reply-To: <350E7D38B6D819428718949920EC23554789336003@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <676F9CCC1D1D3242BE4B133746E3807E53CD65@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789335EFA@NA-EXMSG-C102.redmond.corp.microsoft.com><676F9CCC1D1D3242BE4B133746E3807E53CD68@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789335F3D@NA-EXMSG-C102.redmond.corp.microsoft.com><676F9CCC1D1D3242BE4B133746E3807E53CD69@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789335F3F@NA-EXMSG-C102.redmond.corp.microsoft.com><676F9CCC1D1D3242BE4B133746E3807E53CD70@XARA.cubido.linz> <350E7D38B6D819428718949920EC23554789336003@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <676F9CCC1D1D3242BE4B133746E3807E53CE0C@XARA.cubido.linz> My initial question was if it is possible to debug code that is executed with ScriptSource.Execute(string) - so I do not have a file. If having a file is important I can 'in debug mode' save my code before executing. To answer your question - if I use a filename (ex.: 'C:\Temp\script.py') I can set breakpoints there - and they will stop execution. Only when using 'System.Diagnostics.Debugging.Break()' only a decompiled code is shown. Using this Code is preferred because I normally do not have the script beforehand - it is partly generated. Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Montag, 13. Oktober 2008 18:03 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code How is the filename specified in the Create call? Is it a full path? If you just open the file in VS does VS recognize the code (e.g. can you set breakpoints)? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 10:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code Now is't working partly - i used a app.config which apearently does not setup debugging right. What is not working is that I get only a disassembly - no source code attached. Is there something to setup before? Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Montag, 13. Oktober 2008 07:15 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code Oh, sorry, it looks like it needs to be a bool, not "true" in quotes... With that in mind this works for me: Dictionary options = new Dictionary(); options["Debug"] = true; ScriptEngine engine = Python.CreateEngine(options); ScriptSource source = engine.CreateScriptSourceFromFile("C:\\Users\\Dino\\test.py"); source.Execute(); I can put breakpoints in test.py and hit them. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 10:02 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code No - i get the Call Stack showed below [Lightweight Function] > Microsoft.Scripting.dll!Microsoft.Scripting.Runtime.OptimizedScriptCode. InvokeTarget(Microsoft.Linq.Expressions.LambdaExpression code = {Microsoft.Linq.Expressions.Expression}, Microsoft.Scripting.Runtime.Scope scope = {Microsoft.Scripting.Runtime.Scope}) + 0x1c6 bytes Microsoft.Scripting.dll!Microsoft.Scripting.ScriptCode.Run(Microsoft.Scr ipting.Runtime.Scope scope = {Microsoft.Scripting.Runtime.Scope}) + 0x42 bytes Microsoft.Scripting.dll!Microsoft.Scripting.Hosting.CompiledCode.Execute (Microsoft.Scripting.Hosting.ScriptScope scope = {Microsoft.Scripting.Hosting.ScriptScope}) + 0x77 bytes ... Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Montag, 13. Oktober 2008 06:55 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code If you right click in the call stack window and check Show External Code do you see the code then? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 9:53 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code I got as far as that - when the breakpoint is hit - VS pops up but not in some python code but in the call to Execute - the python code is marked as external code. So is there a possibility to have VS show the script code? Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Sonntag, 12. Oktober 2008 21:21 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code You can set DebugMode = true on a ScriptRuntimeSetup object. If you're using the Python class you can pass a Dictionary object to CreateRuntime with "Debug" = "true" and we'll set it for you. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 12:10 PM To: Users at lists.ironpython.com Subject: [IronPython] Debugging IronPython script code Hallo all, is there a possibility to debug IronPython code that is executed with ScriptSource.Execute or CompiledCode.Execute within VisualStudio? Setting breakpoints in the python code will can be done by System.Diagnostics.Debugger.Break() - the code breaks but I don't know how to tell VS to get into my code. Rainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From kamil at dworakowski.name Tue Oct 14 12:00:22 2008 From: kamil at dworakowski.name (Kamil Dworakowski) Date: Tue, 14 Oct 2008 11:00:22 +0100 Subject: [IronPython] parallel importing In-Reply-To: <350E7D38B6D819428718949920EC235547893360E8@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> <93fc29d60810130906x513c8070u1cda62d926710c0b@mail.gmail.com> <350E7D38B6D819428718949920EC23554789336034@NA-EXMSG-C102.redmond.corp.microsoft.com> <93fc29d60810130941t4d3d5576w68ccf5ffc38aff47@mail.gmail.com> <350E7D38B6D819428718949920EC235547893360E8@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <93fc29d60810140300tc5289c6k578b119978e43d66@mail.gmail.com> No need anymore; we will wait till IronPython 2.0 or next 1.x release. On Mon, Oct 13, 2008 at 7:20 PM, Dino Viehland wrote: > Yep, give me a bit of time - I'll try and get it later today or tomorrow... > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski > Sent: Monday, October 13, 2008 9:42 AM > To: Discussion of IronPython > Subject: Re: [IronPython] parallel importing > > Could you provide a patch? > > On Mon, Oct 13, 2008 at 5:31 PM, Dino Viehland wrote: >> Making the code changes is easy - the hard part is really doing a new 1.x release and all of the sign off work that entails. We haven't ruled it out but we sure would like to avoid it if possible. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski >> Sent: Monday, October 13, 2008 9:07 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] parallel importing >> >> Would that be easy to backport fix for #2 to 1.x branch? >> >> On Mon, Oct 13, 2008 at 5:00 PM, Dino Viehland wrote: >>> This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are locking but on the wrong object in 1.x). >>> >>> #2 is still broken in 2.x though as well. >>> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski >>> Sent: Monday, October 13, 2008 4:45 AM >>> To: users at lists.ironpython.com >>> Subject: [IronPython] parallel importing >>> >>> Importing time is such a pain that I wanted to do it in parallel on >>> many threads. I figured that if the modules where imported in such a >>> way that: >>> >>> no two threads import the same module at the same time >>> >>> everything would be fine. To ensure that condition, it is enough to >>> build a dependency graph and import based on that. >>> >>> I did it: Resolver One start up time improved by 20% on a two-core >>> machine. But it crashes, surprisingly on single core machines it is >>> more often (6 crashes on 200 starts). >>> >>> So far I have identified two causes for crashes: >>> >>> 1. One thread imports a module with class B inside while another is >>> importing a module with class C inside. If B and C are subclasses of >>> A, it can result in IndexOutOfRangeException being raised, when, under >>> the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is being >>> executed. >>> >>> 2. Attributes on .NET modules are loaded lazily, so importing >>> namespaces only is not enough. Attribute getting from reflected >>> packages is not thread safe. Looks like I would have to import every >>> class explicitly (would that be enough?). >>> >>> Second cause would be pretty easy to address, but I'm not so sure >>> about the first one. Are there any more potential points of problems? >>> I am beginning to think I was to optimistic about all of this >>> importing on multiple cores, but if these are the only ones it could >>> probably be still fixed. >>> >>> If anyone is interested the code for it is on github: >>> http://github.com/luntain/ipy-parallel-import. >>> >>> -- >>> Kamil Dworakowski >>> Resolver Systems Ltd. >>> _______________________________________________ >>> 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 kamil at dworakowski.name Tue Oct 14 12:06:58 2008 From: kamil at dworakowski.name (Kamil Dworakowski) Date: Tue, 14 Oct 2008 11:06:58 +0100 Subject: [IronPython] parallel importing In-Reply-To: <350E7D38B6D819428718949920EC23554FF5D2E786@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <93fc29d60810130444r3f88ba66uf610a60673e80f5@mail.gmail.com> <350E7D38B6D819428718949920EC23554789335FFC@NA-EXMSG-C102.redmond.corp.microsoft.com> <93fc29d60810130906x513c8070u1cda62d926710c0b@mail.gmail.com> <350E7D38B6D819428718949920EC23554789336034@NA-EXMSG-C102.redmond.corp.microsoft.com> <93fc29d60810130941t4d3d5576w68ccf5ffc38aff47@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF5D2E786@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <93fc29d60810140306k6cf9752g4c2142d04e55b497@mail.gmail.com> Thx, Dino. I didn't see this email when replying to your previous message, Gmail is not yet perfect :(. At Resolver Systems we don't want to ship customly modified IronPython dlls. On Tue, Oct 14, 2008 at 12:10 AM, Dino Viehland wrote: > Attached is a unified diff of the changes (supposedly equivalent to diff -u). Let me know if some other diff format would be better. > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski > Sent: Monday, October 13, 2008 9:42 AM > To: Discussion of IronPython > Subject: Re: [IronPython] parallel importing > > Could you provide a patch? > > On Mon, Oct 13, 2008 at 5:31 PM, Dino Viehland wrote: >> Making the code changes is easy - the hard part is really doing a new 1.x release and all of the sign off work that entails. We haven't ruled it out but we sure would like to avoid it if possible. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski >> Sent: Monday, October 13, 2008 9:07 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] parallel importing >> >> Would that be easy to backport fix for #2 to 1.x branch? >> >> On Mon, Oct 13, 2008 at 5:00 PM, Dino Viehland wrote: >>> This is all still on 1.x, right? It looks like #1 is fixed in 2.0 (we are locking but on the wrong object in 1.x). >>> >>> #2 is still broken in 2.x though as well. >>> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Kamil Dworakowski >>> Sent: Monday, October 13, 2008 4:45 AM >>> To: users at lists.ironpython.com >>> Subject: [IronPython] parallel importing >>> >>> Importing time is such a pain that I wanted to do it in parallel on >>> many threads. I figured that if the modules where imported in such a >>> way that: >>> >>> no two threads import the same module at the same time >>> >>> everything would be fine. To ensure that condition, it is enough to >>> build a dependency graph and import based on that. >>> >>> I did it: Resolver One start up time improved by 20% on a two-core >>> machine. But it crashes, surprisingly on single core machines it is >>> more often (6 crashes on 200 starts). >>> >>> So far I have identified two causes for crashes: >>> >>> 1. One thread imports a module with class B inside while another is >>> importing a module with class C inside. If B and C are subclasses of >>> A, it can result in IndexOutOfRangeException being raised, when, under >>> the hood, IronPython.Runtime.Types.DynamicType.AddSubclass is being >>> executed. >>> >>> 2. Attributes on .NET modules are loaded lazily, so importing >>> namespaces only is not enough. Attribute getting from reflected >>> packages is not thread safe. Looks like I would have to import every >>> class explicitly (would that be enough?). >>> >>> Second cause would be pretty easy to address, but I'm not so sure >>> about the first one. Are there any more potential points of problems? >>> I am beginning to think I was to optimistic about all of this >>> importing on multiple cores, but if these are the only ones it could >>> probably be still fixed. >>> >>> If anyone is interested the code for it is on github: >>> http://github.com/luntain/ipy-parallel-import. >>> >>> -- >>> Kamil Dworakowski >>> Resolver Systems Ltd. >>> _______________________________________________ >>> 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 r.worbis at cubido.at Tue Oct 14 12:50:30 2008 From: r.worbis at cubido.at (Rainer Worbis) Date: Tue, 14 Oct 2008 12:50:30 +0200 Subject: [IronPython] Debugging IronPython script code In-Reply-To: <676F9CCC1D1D3242BE4B133746E3807E53CE0C@XARA.cubido.linz> References: <676F9CCC1D1D3242BE4B133746E3807E53CD65@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789335EFA@NA-EXMSG-C102.redmond.corp.microsoft.com><676F9CCC1D1D3242BE4B133746E3807E53CD68@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789335F3D@NA-EXMSG-C102.redmond.corp.microsoft.com><676F9CCC1D1D3242BE4B133746E3807E53CD69@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789335F3F@NA-EXMSG-C102.redmond.corp.microsoft.com><676F9CCC1D1D3242BE4B133746E3807E53CD70@XARA.cubido.linz><350E7D38B6D819428718949920EC23554789336003@NA-EXMSG-C102.redmond.corp.microsoft.com> <676F9CCC1D1D3242BE4B133746E3807E53CE0C@XARA.cubido.linz> Message-ID: <676F9CCC1D1D3242BE4B133746E3807E599CD8@XARA.cubido.linz> I have solved my problem: * I have to save the script (in case it contains "Debugger.Break()") to a location where VS can read it (I use a file that is included in my project) * When the Debugger.Break() is hit I have to press F10 a few times (stepping out of Debugger.Break()) and then VS opens the script file Thanks for all the hints. Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Rainer Worbis Gesendet: Dienstag, 14. Oktober 2008 07:04 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code My initial question was if it is possible to debug code that is executed with ScriptSource.Execute(string) - so I do not have a file. If having a file is important I can 'in debug mode' save my code before executing. To answer your question - if I use a filename (ex.: 'C:\Temp\script.py') I can set breakpoints there - and they will stop execution. Only when using 'System.Diagnostics.Debugging.Break()' only a decompiled code is shown. Using this Code is preferred because I normally do not have the script beforehand - it is partly generated. Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Montag, 13. Oktober 2008 18:03 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code How is the filename specified in the Create call? Is it a full path? If you just open the file in VS does VS recognize the code (e.g. can you set breakpoints)? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 10:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code Now is't working partly - i used a app.config which apearently does not setup debugging right. What is not working is that I get only a disassembly - no source code attached. Is there something to setup before? Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Montag, 13. Oktober 2008 07:15 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code Oh, sorry, it looks like it needs to be a bool, not "true" in quotes... With that in mind this works for me: Dictionary options = new Dictionary(); options["Debug"] = true; ScriptEngine engine = Python.CreateEngine(options); ScriptSource source = engine.CreateScriptSourceFromFile("C:\\Users\\Dino\\test.py"); source.Execute(); I can put breakpoints in test.py and hit them. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 10:02 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code No - i get the Call Stack showed below [Lightweight Function] > Microsoft.Scripting.dll!Microsoft.Scripting.Runtime.OptimizedScriptCode. InvokeTarget(Microsoft.Linq.Expressions.LambdaExpression code = {Microsoft.Linq.Expressions.Expression}, Microsoft.Scripting.Runtime.Scope scope = {Microsoft.Scripting.Runtime.Scope}) + 0x1c6 bytes Microsoft.Scripting.dll!Microsoft.Scripting.ScriptCode.Run(Microsoft.Scr ipting.Runtime.Scope scope = {Microsoft.Scripting.Runtime.Scope}) + 0x42 bytes Microsoft.Scripting.dll!Microsoft.Scripting.Hosting.CompiledCode.Execute (Microsoft.Scripting.Hosting.ScriptScope scope = {Microsoft.Scripting.Hosting.ScriptScope}) + 0x77 bytes ... Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Montag, 13. Oktober 2008 06:55 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code If you right click in the call stack window and check Show External Code do you see the code then? From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 9:53 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging IronPython script code I got as far as that - when the breakpoint is hit - VS pops up but not in some python code but in the call to Execute - the python code is marked as external code. So is there a possibility to have VS show the script code? Rainer Von: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] Im Auftrag von Dino Viehland Gesendet: Sonntag, 12. Oktober 2008 21:21 An: Discussion of IronPython Betreff: Re: [IronPython] Debugging IronPython script code You can set DebugMode = true on a ScriptRuntimeSetup object. If you're using the Python class you can pass a Dictionary object to CreateRuntime with "Debug" = "true" and we'll set it for you. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Rainer Worbis Sent: Sunday, October 12, 2008 12:10 PM To: Users at lists.ironpython.com Subject: [IronPython] Debugging IronPython script code Hallo all, is there a possibility to debug IronPython code that is executed with ScriptSource.Execute or CompiledCode.Execute within VisualStudio? Setting breakpoints in the python code will can be done by System.Diagnostics.Debugger.Break() - the code breaks but I don't know how to tell VS to get into my code. Rainer -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.eloff at gmail.com Thu Oct 16 05:10:43 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Wed, 15 Oct 2008 22:10:43 -0500 Subject: [IronPython] What's the situation on being able to accept patches? In-Reply-To: <350E7D38B6D819428718949920EC23554FF5D2E77B@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <4817b6fc0810130952m1ea6a2c7k436295f679399350@mail.gmail.com> <48F38229.907@voidspace.org.uk> <4817b6fc0810131121m3d46b1cdt3de5d85b04043e4b@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF5D2E61E@NA-EXMSG-C102.redmond.corp.microsoft.com> <4817b6fc0810131549h1d5e9cf8h45c2e6819c78292f@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF5D2E77B@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <4817b6fc0810152010w32f9a557sd3f0b35905e57433@mail.gmail.com> Ok, I made the changes, PerformModuleReload is called, SetName is called, but only the builtin compile is called, the one on CompileHelper is never called. Any idea why? Here's my code: http://csharp.pastebin.com/m5a3d08cd Thanks, -Dan From dan.eloff at gmail.com Thu Oct 16 06:46:26 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Wed, 15 Oct 2008 23:46:26 -0500 Subject: [IronPython] What's the situation on being able to accept patches? In-Reply-To: <4817b6fc0810152010w32f9a557sd3f0b35905e57433@mail.gmail.com> References: <4817b6fc0810130952m1ea6a2c7k436295f679399350@mail.gmail.com> <48F38229.907@voidspace.org.uk> <4817b6fc0810131121m3d46b1cdt3de5d85b04043e4b@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF5D2E61E@NA-EXMSG-C102.redmond.corp.microsoft.com> <4817b6fc0810131549h1d5e9cf8h45c2e6819c78292f@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF5D2E77B@NA-EXMSG-C102.redmond.corp.microsoft.com> <4817b6fc0810152010w32f9a557sd3f0b35905e57433@mail.gmail.com> Message-ID: <4817b6fc0810152146u12cac44aod1419fd43e61907b@mail.gmail.com> I figured it out. It seems that depending on where the compile calls are located, they might call the old or the new compile function. import _ast compile(...) # old compile __builtins__.compile(...) # new compile I'm looking into how to get the new compile without messing up mako's code any more than absolutely required. Thanks for the code. It works, and I never would have figured it out without your help. -Dan On Wed, Oct 15, 2008 at 10:10 PM, Dan Eloff wrote: > Ok, I made the changes, PerformModuleReload is called, SetName is > called, but only the builtin compile is called, the one on > CompileHelper is never called. Any idea why? Here's my code: > http://csharp.pastebin.com/m5a3d08cd > > Thanks, > -Dan > From fuzzyman at voidspace.org.uk Thu Oct 16 15:39:50 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 16 Oct 2008 14:39:50 +0100 Subject: [IronPython] What happened to source drops? In-Reply-To: References: <4817b6fc0809291323k52a7dc6cj9976fcb5ac6ce290@mail.gmail.com> <350E7D38B6D819428718949920EC235547877B9A24@NA-EXMSG-C102.redmond.corp.microsoft.com> <48E14564.1050403@voidspace.org.uk> <350E7D38B6D819428718949920EC235547877B9A48@NA-EXMSG-C102.redmond.corp.microsoft.com> <48E148C3.9030207@voidspace.org.uk> <350E7D38B6D819428718949920EC235547877B9A65@NA-EXMSG-C102.redmond.corp.microsoft.com> <48E27B15.3010701@voidspace.org.uk> Message-ID: <48F74426.1080102@voidspace.org.uk> Dave Fugate wrote: > The sources have just been updated and I believe this includes the changes you wanted. > > Cool, thanks. We'll try it out. Michael > Dave > > -----Original Message----- > From: Dave Fugate > Sent: Wednesday, October 01, 2008 8:52 AM > To: Discussion of IronPython > Subject: RE: [IronPython] What happened to source drops? > > My best guess is the fixes will be in the 2.0 branch sometime next week. Offhand, I don't believe the package/module compiling fixes are in yet (e.g., the cyclic dependencies bug is fixed in 2.1, but not 2.0). > > Dave > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Tuesday, September 30, 2008 12:17 PM > To: Discussion of IronPython > Subject: Re: [IronPython] What happened to source drops? > > Dave Fugate wrote: > >> Actually there was a little confusion internally and the 40877 changeset uploaded to CodePlex yesterday corresponds to our new IronPython 2.1 branch. In turn, the 2.1 branch was the reason there's been no source pushes for the past two weeks - some scripts and TFS enlistments needed updating to re-enable IP 2.0 source updates. >> >> The latest update, changeset 40917, comes from our IronPython 2.0 branch and does not yet include most of the fixes in changeset 40877. If you want these now (and possibly some changes that won't be making it into IP 2.0), use http://www.codeplex.com/IronPython/SourceControl/DownloadSourceCode.aspx?changeSetId=40877. Otherwise, we hope to have the fixes included in TFS within a week. Sorry for any confusion about this. >> >> >> > > No problem. Any ETA on getting the features that will make it in to 2.0 > available in a code drop? Are the 'compiling packages' fixes in the > current 2.0 branch code drop? > > Michael > > >> Dave >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Srivatsn Narayanan >> Sent: Monday, September 29, 2008 3:12 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] What happened to source drops? >> >> I've pushed out a source drop with the latest sources - http://www.codeplex.com/IronPython/SourceControl/ListDownloadableCommits.aspx >> >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland >> Sent: Monday, September 29, 2008 2:40 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] What happened to source drops? >> >> I would actually suggest compiling the standard modules as well as your code and then ngen them both on install. You can compile the std modules into their own .dll so the user can always replace them w/ their own version (or they can simply delete the DLL and then pick up the .py files). >> >> The reason I suggest this is with the bits on my machine I'm seeing massive import speed ups w/ pre-compilation + ngen (e.g. 3x or so). >> >> And decimal does import a lot more - but the real working set hit came from publishing all the SymbolIDs for every precompiled module - once for each module - on startup! A small oversight :)... But there were a few other areas that could use some improvement as well. >> >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Monday, September 29, 2008 2:30 PM >> To: Discussion of IronPython >> Subject: Re: [IronPython] What happened to source drops? >> >> Dino Viehland wrote: >> >> >>> They're checked in so they'll be in the next source push. There are some perf problems that I have fixes for though that aren't checked in (e.g. import decimal in pre-compiled currently allocates ~550MB of memory) - but you should be able to do functional testing :). I'll should have the pre-comp perf fixes in this week. >>> >>> >>> >> Cool - thanks. 550mb for one module - wow. Good job we aren't intending >> to precompile the Python standard library modules we're using. Having >> said that we have quite a chunk of Python source we would like to >> compile - I wonder if a 4gb address space will be enough. I think we >> will be reluctant to move to 64bit oses only... ;-) >> >> Michael >> >> >> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >>> Sent: Monday, September 29, 2008 2:15 PM >>> To: Discussion of IronPython >>> Subject: Re: [IronPython] What happened to source drops? >>> >>> Dino Viehland wrote: >>> >>> >>> >>>> It looks like the script which automatically publishes the code has stopped publishing the updates. Dave's OOF today and I can't find the original instructions but Sri's looking into it. >>>> >>>> >>>> >>>> >>> Cool. If you get the compiling packages fixes into a code drop please >>> let me know so that we can start testing them early. >>> >>> Thanks >>> >>> Michael Foord >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff >>>> Sent: Monday, September 29, 2008 1:23 PM >>>> To: Discussion of IronPython >>>> Subject: [IronPython] What happened to source drops? >>>> >>>> I'm noticing that the last source drop was the beta 5 release two weeks ago. >>>> >>>> I don't mean to pressure you guys, but I am looking forward to the >>>> next source release, which seems to have the delegate regressions >>>> fixed. Any (vague) idea of when regular source drops will be resumed? >>>> >>>> By the way, I built IronPython b5 for Silverlight RC0, and I had to >>>> modify Microsoft.Scripting.Silverlight.ErrorFormatter: >>>> >>>> - HtmlPage.Document.GetElementsByTagName("body")[0].AppendChild(target); >>>> + ((HtmlElement)HtmlPage.Document.GetElementsByTagName("body")[0]).AppendChild(target); >>>> >>>> I'm not fully sure how this code compiled in the first place, as >>>> ScriptObject never had an AppendChild method. Probably this code has >>>> already been fixed, but it's worth checking anyway. >>>> >>>> -Dan >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.ironpython.com >>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.ironpython.com >>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>>> >>>> >>>> >>>> >>> -- >>> http://www.ironpythoninaction.com/ >>> http://www.voidspace.org.uk/ >>> http://www.trypython.org/ >>> http://www.ironpython.info/ >>> http://www.theotherdelia.co.uk/ >>> http://www.resolverhacks.net/ >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >> -- >> http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/ >> http://www.trypython.org/ >> http://www.ironpython.info/ >> http://www.theotherdelia.co.uk/ >> http://www.resolverhacks.net/ >> >> _______________________________________________ >> 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 >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/ > http://www.trypython.org/ > http://www.ironpython.info/ > http://www.theotherdelia.co.uk/ > http://www.resolverhacks.net/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From dinov at microsoft.com Thu Oct 16 17:42:00 2008 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 16 Oct 2008 08:42:00 -0700 Subject: [IronPython] What's the situation on being able to accept patches? In-Reply-To: <4817b6fc0810152146u12cac44aod1419fd43e61907b@mail.gmail.com> References: <4817b6fc0810130952m1ea6a2c7k436295f679399350@mail.gmail.com> <48F38229.907@voidspace.org.uk> <4817b6fc0810131121m3d46b1cdt3de5d85b04043e4b@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF5D2E61E@NA-EXMSG-C102.redmond.corp.microsoft.com> <4817b6fc0810131549h1d5e9cf8h45c2e6819c78292f@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF5D2E77B@NA-EXMSG-C102.redmond.corp.microsoft.com> <4817b6fc0810152010w32f9a557sd3f0b35905e57433@mail.gmail.com> <4817b6fc0810152146u12cac44aod1419fd43e61907b@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23554FF5D2F364@NA-EXMSG-C102.redmond.corp.microsoft.com> This is because we're not firing the module changed event. This seems like a bug, we should probably use a special dictionary here. You can call ScopeOps.SetMember() and it'll also deliver the event. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dan Eloff Sent: Wednesday, October 15, 2008 9:46 PM To: Discussion of IronPython Subject: Re: [IronPython] What's the situation on being able to accept patches? I figured it out. It seems that depending on where the compile calls are located, they might call the old or the new compile function. import _ast compile(...) # old compile __builtins__.compile(...) # new compile I'm looking into how to get the new compile without messing up mako's code any more than absolutely required. Thanks for the code. It works, and I never would have figured it out without your help. -Dan On Wed, Oct 15, 2008 at 10:10 PM, Dan Eloff wrote: > Ok, I made the changes, PerformModuleReload is called, SetName is > called, but only the builtin compile is called, the one on > CompileHelper is never called. Any idea why? Here's my code: > http://csharp.pastebin.com/m5a3d08cd > > Thanks, > -Dan > _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From wl2776 at gmail.com Fri Oct 17 11:43:02 2008 From: wl2776 at gmail.com (Vladimir Eremeev) Date: Fri, 17 Oct 2008 02:43:02 -0700 (PDT) Subject: [IronPython] How to set a namespace for IronPython classes? Message-ID: <20030145.post@talk.nabble.com> Hi all. I am very new to the IronPython and to .NET I have installed IronPython v2.0 beta 5 and the IronPythonStudio, integrated in MS VisualStudio 2008. I have created a simple IronPython project containing one form and compiled it to the class library. However, when I have opened the resulting DLL in the Studio's Object Browser, I have seen that classes are in the global namespace, while other system classes are in their own namespaces. How do I create a namespace and put my classes to it? -- View this message in context: http://www.nabble.com/How-to-set-a-namespace-for-IronPython-classes--tp20030145p20030145.html Sent from the IronPython mailing list archive at Nabble.com. From fuzzyman at voidspace.org.uk Fri Oct 17 14:26:16 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 17 Oct 2008 13:26:16 +0100 Subject: [IronPython] How to set a namespace for IronPython classes? In-Reply-To: <20030145.post@talk.nabble.com> References: <20030145.post@talk.nabble.com> Message-ID: <48F88468.6000806@voidspace.org.uk> Vladimir Eremeev wrote: > Hi all. > I am very new to the IronPython and to .NET > > I have installed IronPython v2.0 beta 5 and the IronPythonStudio, > integrated in MS VisualStudio 2008. > > I have created a simple IronPython project containing one form and compiled > it to the class library. > However, when I have opened the resulting DLL in the Studio's Object > Browser, I have seen that classes are in the global namespace, while other > system classes are in their own namespaces. > > How do I create a namespace and put my classes to it? > > > Hello Vladimir, Python as a language uses modules and packages to do namespacing rather than .NET namespaces. This means that introspecting assemblies compiled from Python code to examine their *structure* is not really useful. If you want to *use* those classes from .NET (say from C#) you will need to do it through the IronPython hosting API rather than directly referencing the compiled assemblies anyway. What are you actually trying to achieve? Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ From wl2776 at gmail.com Fri Oct 17 15:00:58 2008 From: wl2776 at gmail.com (Vladimir Eremeev) Date: Fri, 17 Oct 2008 06:00:58 -0700 (PDT) Subject: [IronPython] How to set a namespace for IronPython classes? In-Reply-To: <48F88468.6000806@voidspace.org.uk> References: <20030145.post@talk.nabble.com> <48F88468.6000806@voidspace.org.uk> Message-ID: <20032865.post@talk.nabble.com> Michael Foord-5 wrote: > > If you want to *use* those classes from .NET (say from C#) you will need > to do it through the IronPython hosting API rather than directly > referencing the compiled assemblies anyway. > Do you mean this? http://remark.wordpress.com/2008/09/23/running-python-from-c/ Michael Foord-5 wrote: > > What are you actually trying to achieve? > Currently nothing specific, just simple experiments during the spare time. I am studying the possibilities to use IronPython for development. My colleagues use C#, but I don't like this language (it's subjective), I am looking for covenient ways to collaborate with them and to contribute the code for our projects. -- View this message in context: http://www.nabble.com/How-to-set-a-namespace-for-IronPython-classes--tp20030145p20032865.html Sent from the IronPython mailing list archive at Nabble.com. From fuzzyman at voidspace.org.uk Fri Oct 17 15:04:29 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 17 Oct 2008 14:04:29 +0100 Subject: [IronPython] How to set a namespace for IronPython classes? In-Reply-To: <20032865.post@talk.nabble.com> References: <20030145.post@talk.nabble.com> <48F88468.6000806@voidspace.org.uk> <20032865.post@talk.nabble.com> Message-ID: <48F88D5D.80505@voidspace.org.uk> Vladimir Eremeev wrote: > Michael Foord-5 wrote: > >> If you want to *use* those classes from .NET (say from C#) you will need >> to do it through the IronPython hosting API rather than directly >> referencing the compiled assemblies anyway. >> >> > Do you mean this? > http://remark.wordpress.com/2008/09/23/running-python-from-c/ > > > That kind of thing yes. There are a list of interesting resources on the subject here: http://ironpython-urls.blogspot.com/search/label/embedding This is only for interacting with IronPython from C#. If you can do everything from inside IronPython - or just using C# classes from inside IronPython rather than the other way round - then you don't need to worry about the hosting API. In this case it is worth reading some Python tutorials to see how Python does its namespacing and application / library structuring (modules and packages). Michael > Michael Foord-5 wrote: > >> What are you actually trying to achieve? >> >> > Currently nothing specific, just simple experiments during the spare time. > I am studying the possibilities to use IronPython for development. > My colleagues use C#, but I don't like this language (it's subjective), I am > looking for covenient ways to collaborate with them and to contribute the > code for our projects. > -- http://www.ironpythoninaction.com/ From sanxiyn at gmail.com Sat Oct 18 14:33:16 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Sat, 18 Oct 2008 21:33:16 +0900 Subject: [IronPython] CodePlex SVN is a crap Message-ID: <5b0248170810180533g4a769c92v9453b57423c375a5@mail.gmail.com> I tried for some time to use https://ironpython.svn.codeplex.com/svn instead of CodePlex Source Code tab .zip download, but it's unusable. I routinely get: svn: Server sent unexpected return value (500 Internal Server Error) in response to REPORT request for '/svn/!svn/vcc/default' or some such stuffs. Can someone pester the right people to get this to work correctly? svn, version 1.5.1 (r32289) -- Seo Sanghyeon From jdhardy at gmail.com Sat Oct 18 16:44:33 2008 From: jdhardy at gmail.com (Jeff Hardy) Date: Sat, 18 Oct 2008 08:44:33 -0600 Subject: [IronPython] IronPython and the GAC Message-ID: Hello, Has there been any consideration to having the installer put the DLR and IronPython assemblies in the GAC? It would greatly simplify NWSGI deployment, since NWSGI goes in the GAC when installed with IIS7 integration to make configuration and deployment much easier. Having the IPy assemblies in the GAC would simplify the deployment instructions to 1) install IronPython 2.0; 2) install NWSGI; 3) configure application. If not, I'll just provide instructions for how to add them manually, but this seems like something that should be oofficially supported. -Jeff From sidnei.da.silva at gmail.com Sat Oct 18 16:47:54 2008 From: sidnei.da.silva at gmail.com (Sidnei da Silva) Date: Sat, 18 Oct 2008 11:47:54 -0300 Subject: [IronPython] CodePlex SVN is a crap In-Reply-To: <5b0248170810180533g4a769c92v9453b57423c375a5@mail.gmail.com> References: <5b0248170810180533g4a769c92v9453b57423c375a5@mail.gmail.com> Message-ID: May I suggest mirroring the Ironpython source somewhere? I could setup a project in Launchpad and import it into bzr if anyone is interested (and if that would be allowed)? On Sat, Oct 18, 2008 at 9:33 AM, Seo Sanghyeon wrote: > I tried for some time to use https://ironpython.svn.codeplex.com/svn > instead of CodePlex Source Code tab .zip download, but it's unusable. > I routinely get: > > svn: Server sent unexpected return value (500 Internal Server Error) > in response to REPORT request for '/svn/!svn/vcc/default' > > or some such stuffs. Can someone pester the right people to get this > to work correctly? > > svn, version 1.5.1 (r32289) > > -- > Seo Sanghyeon > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Sidnei da Silva Enfold Systems http://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 From jtgalyon at gmail.com Sat Oct 18 17:13:35 2008 From: jtgalyon at gmail.com (Jason Galyon) Date: Sat, 18 Oct 2008 10:13:35 -0500 Subject: [IronPython] CodePlex SVN is a crap In-Reply-To: References: <5b0248170810180533g4a769c92v9453b57423c375a5@mail.gmail.com> Message-ID: <48F9FD1F.5070505@gmail.com> Sidnei da Silva wrote: > May I suggest mirroring the Ironpython source somewhere? I could setup > a project in Launchpad and import it into bzr if anyone is interested > (and if that would be allowed)? > > On Sat, Oct 18, 2008 at 9:33 AM, Seo Sanghyeon wrote: > >> I tried for some time to use https://ironpython.svn.codeplex.com/svn >> instead of CodePlex Source Code tab .zip download, but it's unusable. >> I routinely get: >> >> svn: Server sent unexpected return value (500 Internal Server Error) >> in response to REPORT request for '/svn/!svn/vcc/default' >> >> or some such stuffs. Can someone pester the right people to get this >> to work correctly? >> >> svn, version 1.5.1 (r32289) >> >> -- >> Seo Sanghyeon >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > > I second that, if only to allow for the more modern use-case of distributed version control. It is great to have your own revisions on your working copy then once done to commit it. This is cleaner than creating your own branch in the 'old model' RCS like CVS and SVN. Plus, Launchpad is an excellent collaborative system. Jason From dan.eloff at gmail.com Sat Oct 18 21:55:05 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Sat, 18 Oct 2008 14:55:05 -0500 Subject: [IronPython] How can you create set/frozenset from C# ? Message-ID: <4817b6fc0810181255o40781323uaf62e362f8110d00@mail.gmail.com> It seems to me that you have to use __init__/__new__ supplying CodeContext as necessary. Unlike list and tuple which have public constructors and PythonOps helpers, there doesn't seem to be any public api for creating sets. Am I right? Thanks, -Dan From curt at hagenlocher.org Mon Oct 20 00:58:39 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Sun, 19 Oct 2008 15:58:39 -0700 Subject: [IronPython] IronPython and the GAC In-Reply-To: References: Message-ID: I believe that the RC1 installer will have the option of GACing and/or NGENing IronPython. And if so, I'm hoping that we hadn't intended that to be a surprise, as I would now be spoiling it. ;) On Sat, Oct 18, 2008 at 7:44 AM, Jeff Hardy wrote: > Hello, > Has there been any consideration to having the installer put the DLR > and IronPython assemblies in the GAC? It would greatly simplify NWSGI > deployment, since NWSGI goes in the GAC when installed with IIS7 > integration to make configuration and deployment much easier. Having > the IPy assemblies in the GAC would simplify the deployment > instructions to 1) install IronPython 2.0; 2) install NWSGI; 3) > configure application. > > If not, I'll just provide instructions for how to add them manually, > but this seems like something that should be oofficially supported. > > -Jeff > _______________________________________________ > 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 xkenneth at gmail.com Mon Oct 20 02:05:31 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Sun, 19 Oct 2008 19:05:31 -0500 Subject: [IronPython] XML Support in IronPython Message-ID: <1821D1EB-05D3-46B7-A1D1-409DA0EFB5D3@gmail.com> All, I've just built my project on top of minidom, for which there is no support in IronPython, so I'm wondering if there are any compatibility abstractions and/or what are my options for XML processing under ironpython? Regards, Ken From sanxiyn at gmail.com Mon Oct 20 04:22:38 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Mon, 20 Oct 2008 11:22:38 +0900 Subject: [IronPython] XML Support in IronPython In-Reply-To: <1821D1EB-05D3-46B7-A1D1-409DA0EFB5D3@gmail.com> References: <1821D1EB-05D3-46B7-A1D1-409DA0EFB5D3@gmail.com> Message-ID: <5b0248170810191922p70439231t7b427dcc635939d3@mail.gmail.com> 2008/10/20 Kenneth Miller : > I've just built my project on top of minidom, for which there is no > support in IronPython, so I'm wondering if there are any compatibility > abstractions and/or what are my options for XML processing under ironpython? Yes there is. Grab pyexpat.py from FePy project and put it on somewhere you can import. Then CPython's minidom will just work. https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/lib/pyexpat.py -- Seo Sanghyeon From vernondcole at gmail.com Mon Oct 20 05:00:07 2008 From: vernondcole at gmail.com (Vernon Cole) Date: Sun, 19 Oct 2008 21:00:07 -0600 Subject: [IronPython] CodePlex SVN is a crap In-Reply-To: <48F9FD1F.5070505@gmail.com> References: <5b0248170810180533g4a769c92v9453b57423c375a5@mail.gmail.com> <48F9FD1F.5070505@gmail.com> Message-ID: And it would make it a lot easier when I start trying to hook storm ( https://storm.canonical.com) into Iron Python really-soon-now. I have not hooked adodbapi into the fePy SVN yet because I'm afraid of breaking something. +1 for bazaar and launchpad. -- Vernon Cole -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdhardy at gmail.com Mon Oct 20 16:03:00 2008 From: jdhardy at gmail.com (Jeff Hardy) Date: Mon, 20 Oct 2008 08:03:00 -0600 Subject: [IronPython] IronPython and the GAC In-Reply-To: References: Message-ID: Good to hear! Thanks, Curt. On Sun, Oct 19, 2008 at 4:58 PM, Curt Hagenlocher wrote: > I believe that the RC1 installer will have the option of GACing and/or > NGENing IronPython. And if so, I'm hoping that we hadn't intended that to > be a surprise, as I would now be spoiling it. ;) > > On Sat, Oct 18, 2008 at 7:44 AM, Jeff Hardy wrote: >> >> Hello, >> Has there been any consideration to having the installer put the DLR >> and IronPython assemblies in the GAC? It would greatly simplify NWSGI >> deployment, since NWSGI goes in the GAC when installed with IIS7 >> integration to make configuration and deployment much easier. Having >> the IPy assemblies in the GAC would simplify the deployment >> instructions to 1) install IronPython 2.0; 2) install NWSGI; 3) >> configure application. >> >> If not, I'll just provide instructions for how to add them manually, >> but this seems like something that should be oofficially supported. >> >> -Jeff >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From fuzzyman at voidspace.org.uk Mon Oct 20 16:47:42 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 20 Oct 2008 15:47:42 +0100 Subject: [IronPython] Compiling Packages with clr.BuildModules and build Message-ID: <48FC9A0E.3010805@voidspace.org.uk> Hello guys, I've been trying to compile Python packages Pyc and the latest sourcecode drop - change set 41685. The good news is that compiling packages works. Even better, compiling packages with sub-packages works. Unfortunately, compiling packages with sub-packages with sub-sub-packages is broken. The generated assemblies have the bottom level paths screwed and so imports from them fail. I can provide a test case if you need it, but it should be straightforward to reproduce. :-) Needless to say this means that we still can't run a binary Resolver on IronPython 2. All the best, Michael Foord -- http://www.ironpythoninaction.com/ From curt at hagenlocher.org Mon Oct 20 18:10:46 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 20 Oct 2008 09:10:46 -0700 Subject: [IronPython] IronPython and the GAC In-Reply-To: References: Message-ID: Of course, I might have gotten it wrong... The current installer allows you to do an NGEN but not a GAC. I think that this might be because GAC gives full trust, which means we'd need to pass a more substantial internal security review. But I'm still looking into it. On Mon, Oct 20, 2008 at 7:03 AM, Jeff Hardy wrote: > Good to hear! Thanks, Curt. > > On Sun, Oct 19, 2008 at 4:58 PM, Curt Hagenlocher > wrote: > > I believe that the RC1 installer will have the option of GACing and/or > > NGENing IronPython. And if so, I'm hoping that we hadn't intended that > to > > be a surprise, as I would now be spoiling it. ;) > > > > On Sat, Oct 18, 2008 at 7:44 AM, Jeff Hardy wrote: > >> > >> Hello, > >> Has there been any consideration to having the installer put the DLR > >> and IronPython assemblies in the GAC? It would greatly simplify NWSGI > >> deployment, since NWSGI goes in the GAC when installed with IIS7 > >> integration to make configuration and deployment much easier. Having > >> the IPy assemblies in the GAC would simplify the deployment > >> instructions to 1) install IronPython 2.0; 2) install NWSGI; 3) > >> configure application. > >> > >> If not, I'll just provide instructions for how to add them manually, > >> but this seems like something that should be oofficially supported. > >> > >> -Jeff > >> _______________________________________________ > >> Users mailing list > >> Users at lists.ironpython.com > >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > _______________________________________________ > 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 xkenneth at gmail.com Mon Oct 20 20:07:39 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Mon, 20 Oct 2008 13:07:39 -0500 Subject: [IronPython] XML Support in IronPython In-Reply-To: <5b0248170810191922p70439231t7b427dcc635939d3@mail.gmail.com> References: <1821D1EB-05D3-46B7-A1D1-409DA0EFB5D3@gmail.com> <5b0248170810191922p70439231t7b427dcc635939d3@mail.gmail.com> Message-ID: All, Seo, Do I simply need to import the module? I'm using the distribution of IronPython distributed with the Silverlight Dynamic Languages SDK. My code still chokes on from xml.dom.minidom import parse Regards, Ken On Oct 19, 2008, at 9:22 PM, Seo Sanghyeon wrote: > 2008/10/20 Kenneth Miller : >> I've just built my project on top of minidom, for which there >> is no >> support in IronPython, so I'm wondering if there are any >> compatibility >> abstractions and/or what are my options for XML processing under >> ironpython? > > Yes there is. Grab pyexpat.py from FePy project and put it on > somewhere you can > import. Then CPython's minidom will just work. > > https://fepy.svn.sourceforge.net/svnroot/fepy/trunk/lib/pyexpat.py > > -- > Seo Sanghyeon > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Oct 20 20:38:46 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 20 Oct 2008 11:38:46 -0700 Subject: [IronPython] Compiling Packages with clr.BuildModules and build In-Reply-To: <48FC9A0E.3010805@voidspace.org.uk> References: <48FC9A0E.3010805@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23554FF6102C0C@NA-EXMSG-C102.redmond.corp.microsoft.com> I believe the fix for this is simple if you want to give it a shot. In ClrModule.cs in BuildPackageMap there is a loop that looks like: do { if (pkgName != string.Empty) { fullName = pkgName + "." + fullName; } dirName = Path.GetDirectoryName(dirName); } while (packageMap.TryGetValue(dirName, out pkgName)); It shouldn't actually be a loop, it should just be: if (packageMap.TryGetValue(Path.GetDirectoryName(dirName), out pkgName)) { fullName = pkgName + "." + fullName; } -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, October 20, 2008 7:48 AM To: Discussion of IronPython Subject: [IronPython] Compiling Packages with clr.BuildModules and build Hello guys, I've been trying to compile Python packages Pyc and the latest sourcecode drop - change set 41685. The good news is that compiling packages works. Even better, compiling packages with sub-packages works. Unfortunately, compiling packages with sub-packages with sub-sub-packages is broken. The generated assemblies have the bottom level paths screwed and so imports from them fail. I can provide a test case if you need it, but it should be straightforward to reproduce. :-) Needless to say this means that we still can't run a binary Resolver on IronPython 2. All the best, Michael Foord -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From sanxiyn at gmail.com Mon Oct 20 20:51:04 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Tue, 21 Oct 2008 03:51:04 +0900 Subject: [IronPython] XML Support in IronPython In-Reply-To: References: <1821D1EB-05D3-46B7-A1D1-409DA0EFB5D3@gmail.com> <5b0248170810191922p70439231t7b427dcc635939d3@mail.gmail.com> Message-ID: <5b0248170810201151v1e83e6b7s26f1cc4fe0f3afad@mail.gmail.com> 2008/10/21 Kenneth Miller : > Do I simply need to import the module? I'm using the distribution of > IronPython distributed with the Silverlight Dynamic Languages SDK. My code > still chokes on from xml.dom.minidom import parse You need to make it importable. You don't actually need to import it, although it shouldn't hurt. Do you have the error message? It works for me. -- Seo Sanghyeon From fuzzyman at voidspace.org.uk Mon Oct 20 20:51:53 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 20 Oct 2008 19:51:53 +0100 Subject: [IronPython] Compiling Packages with clr.BuildModules and build In-Reply-To: <350E7D38B6D819428718949920EC23554FF6102C0C@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <48FC9A0E.3010805@voidspace.org.uk> <350E7D38B6D819428718949920EC23554FF6102C0C@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <48FCD349.8060603@voidspace.org.uk> Dino Viehland wrote: > I believe the fix for this is simple if you want to give it a shot. In ClrModule.cs in BuildPackageMap there is a loop that looks like: > > do { > if (pkgName != string.Empty) { > fullName = pkgName + "." + fullName; > } > > dirName = Path.GetDirectoryName(dirName); > } while (packageMap.TryGetValue(dirName, out pkgName)); > > It shouldn't actually be a loop, it should just be: > > if (packageMap.TryGetValue(Path.GetDirectoryName(dirName), out pkgName)) { > fullName = pkgName + "." + fullName; > } > > > Cool - thanks, I'll try that. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, October 20, 2008 7:48 AM > To: Discussion of IronPython > Subject: [IronPython] Compiling Packages with clr.BuildModules and build > > Hello guys, > > I've been trying to compile Python packages Pyc and the latest > sourcecode drop - change set 41685. > > The good news is that compiling packages works. Even better, compiling > packages with sub-packages works. Unfortunately, compiling packages with > sub-packages with sub-sub-packages is broken. The generated assemblies > have the bottom level paths screwed and so imports from them fail. > > I can provide a test case if you need it, but it should be > straightforward to reproduce. :-) > > Needless to say this means that we still can't run a binary Resolver on > IronPython 2. > > All the best, > > Michael Foord > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From xkenneth at gmail.com Mon Oct 20 22:33:52 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Mon, 20 Oct 2008 15:33:52 -0500 Subject: [IronPython] XML Support in IronPython In-Reply-To: <5b0248170810201151v1e83e6b7s26f1cc4fe0f3afad@mail.gmail.com> References: <1821D1EB-05D3-46B7-A1D1-409DA0EFB5D3@gmail.com> <5b0248170810191922p70439231t7b427dcc635939d3@mail.gmail.com> <5b0248170810201151v1e83e6b7s26f1cc4fe0f3afad@mail.gmail.com> Message-ID: Seo, It's throwing an import error. I downloaded the latest version of mono and ironpython. "mono ipy.exe test.py" test.py simply reads.. "import xml.dom.minidom" Regards, Ken On Oct 20, 2008, at 1:51 PM, Seo Sanghyeon wrote: > 2008/10/21 Kenneth Miller : >> Do I simply need to import the module? I'm using the >> distribution of >> IronPython distributed with the Silverlight Dynamic Languages SDK. >> My code >> still chokes on from xml.dom.minidom import parse > > You need to make it importable. You don't actually need to import > it, although > it shouldn't hurt. > > Do you have the error message? It works for me. > > -- > Seo Sanghyeon > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Oct 20 22:45:11 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 20 Oct 2008 21:45:11 +0100 Subject: [IronPython] XML Support in IronPython In-Reply-To: References: <1821D1EB-05D3-46B7-A1D1-409DA0EFB5D3@gmail.com> <5b0248170810191922p70439231t7b427dcc635939d3@mail.gmail.com> <5b0248170810201151v1e83e6b7s26f1cc4fe0f3afad@mail.gmail.com> Message-ID: <48FCEDD7.6060505@voidspace.org.uk> Hello Kenneth, Are you using FePy? The minidom support Seo was talking about is only in FePy and not the standard IronPython distribution. Michael Kenneth Miller wrote: > Seo, > > It's throwing an import error. I downloaded the latest version of > mono and ironpython. > > "mono ipy.exe test.py" > > test.py simply reads.. > > "import xml.dom.minidom" > > Regards, > Ken > > On Oct 20, 2008, at 1:51 PM, Seo Sanghyeon wrote: > >> 2008/10/21 Kenneth Miller > >: >>> Do I simply need to import the module? I'm using the >>> distribution of >>> IronPython distributed with the Silverlight Dynamic Languages SDK. >>> My code >>> still chokes on from xml.dom.minidom import parse >> >> You need to make it importable. You don't actually need to import it, >> although >> it shouldn't hurt. >> >> Do you have the error message? It works for me. >> >> -- >> 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 > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From sanxiyn at gmail.com Tue Oct 21 13:11:21 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Tue, 21 Oct 2008 20:11:21 +0900 Subject: [IronPython] XML Support in IronPython In-Reply-To: <48FCEDD7.6060505@voidspace.org.uk> References: <1821D1EB-05D3-46B7-A1D1-409DA0EFB5D3@gmail.com> <5b0248170810191922p70439231t7b427dcc635939d3@mail.gmail.com> <5b0248170810201151v1e83e6b7s26f1cc4fe0f3afad@mail.gmail.com> <48FCEDD7.6060505@voidspace.org.uk> Message-ID: <5b0248170810210411p469a8e2m689a6852b1c8e431@mail.gmail.com> 2008/10/21 Michael Foord : > Are you using FePy? The minidom support Seo was talking about is only in > FePy and not the standard IronPython distribution. Doesn't the standard IronPython distribution now include CPython standard library from 2.5, including xml.dom.minidom? -- Seo Sanghyeon From fuzzyman at voidspace.org.uk Tue Oct 21 13:36:39 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 21 Oct 2008 12:36:39 +0100 Subject: [IronPython] XML Support in IronPython In-Reply-To: <5b0248170810210411p469a8e2m689a6852b1c8e431@mail.gmail.com> References: <1821D1EB-05D3-46B7-A1D1-409DA0EFB5D3@gmail.com> <5b0248170810191922p70439231t7b427dcc635939d3@mail.gmail.com> <5b0248170810201151v1e83e6b7s26f1cc4fe0f3afad@mail.gmail.com> <48FCEDD7.6060505@voidspace.org.uk> <5b0248170810210411p469a8e2m689a6852b1c8e431@mail.gmail.com> Message-ID: <48FDBEC7.7000209@voidspace.org.uk> Seo Sanghyeon wrote: > 2008/10/21 Michael Foord : > >> Are you using FePy? The minidom support Seo was talking about is only in >> FePy and not the standard IronPython distribution. >> > > Doesn't the standard IronPython distribution now include CPython > standard library > from 2.5, including xml.dom.minidom? > > Doesn't it require your compatibility work? Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://wwww.theotherdelia.co.uk/ From Harry.Pierson at microsoft.com Tue Oct 21 21:47:27 2008 From: Harry.Pierson at microsoft.com (Harry Pierson) Date: Tue, 21 Oct 2008 12:47:27 -0700 Subject: [IronPython] The Fifth Assembly In-Reply-To: <48FDBEC7.7000209@voidspace.org.uk> References: <1821D1EB-05D3-46B7-A1D1-409DA0EFB5D3@gmail.com> <5b0248170810191922p70439231t7b427dcc635939d3@mail.gmail.com> <5b0248170810201151v1e83e6b7s26f1cc4fe0f3afad@mail.gmail.com> <48FCEDD7.6060505@voidspace.org.uk> <5b0248170810210411p469a8e2m689a6852b1c8e431@mail.gmail.com> <48FDBEC7.7000209@voidspace.org.uk> Message-ID: The latest in our ongoing saga to rid the IPy world of type collisions between DLR and System.Core is live in the latest IPy source drop, v0.4 of the Silverlight Dynamic Languages SDK and the upcoming RC1 release of IronPython 2.0. I detail what the change is and why we did it on my blog: http://devhawk.net/2008/10/21/The+Fifth+Assembly.aspx Let me reiterate this point from my blog post: "If you've got any questions or find any more issues with this solution, please let us know right away." Harry From fuzzyman at voidspace.org.uk Wed Oct 22 17:08:16 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 22 Oct 2008 16:08:16 +0100 Subject: [IronPython] Compiling Packages with clr.BuildModules and build In-Reply-To: <350E7D38B6D819428718949920EC23554FF6102C0C@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <48FC9A0E.3010805@voidspace.org.uk> <350E7D38B6D819428718949920EC23554FF6102C0C@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <48FF41E0.2020407@voidspace.org.uk> Great - Resolver One boiled down to four assemblies and running on IronPython 2. Seems to work great. We've just done a lot of work on making Resolver One start faster so I'm going to restart the port on a 'head' version and see how much quicker an ngen'd binary version is. Thanks Michael Dino Viehland wrote: > I believe the fix for this is simple if you want to give it a shot. In ClrModule.cs in BuildPackageMap there is a loop that looks like: > > do { > if (pkgName != string.Empty) { > fullName = pkgName + "." + fullName; > } > > dirName = Path.GetDirectoryName(dirName); > } while (packageMap.TryGetValue(dirName, out pkgName)); > > It shouldn't actually be a loop, it should just be: > > if (packageMap.TryGetValue(Path.GetDirectoryName(dirName), out pkgName)) { > fullName = pkgName + "." + fullName; > } > > > > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Monday, October 20, 2008 7:48 AM > To: Discussion of IronPython > Subject: [IronPython] Compiling Packages with clr.BuildModules and build > > Hello guys, > > I've been trying to compile Python packages Pyc and the latest > sourcecode drop - change set 41685. > > The good news is that compiling packages works. Even better, compiling > packages with sub-packages works. Unfortunately, compiling packages with > sub-packages with sub-sub-packages is broken. The generated assemblies > have the bottom level paths screwed and so imports from them fail. > > I can provide a test case if you need it, but it should be > straightforward to reproduce. :-) > > Needless to say this means that we still can't run a binary Resolver on > IronPython 2. > > All the best, > > Michael Foord > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From DesLeo at gmail.com Wed Oct 22 18:53:12 2008 From: DesLeo at gmail.com (DesLeo at gmail.com) Date: Wed, 22 Oct 2008 09:53:12 -0700 Subject: [IronPython] Python in an AppDomain Message-ID: <00221532ce0c34796b0459da6247@google.com> Howdy folks, I apologize if this isn't really a Python question, but at the very least it's strongly related to the task at hand. With the latest beta, running Python in an app domain is even easier than before, I'm totally loving it. I just have one question, when creating the low-security appdomain you have the option to pass in a list of fully trusted assemblies. I guess I don't really understand the implications of this, why does the appdomain need to have a list of those? At first I was adding the calling assembly to the list, but even when I don't do so I can still call on the runtime there without issues. My object model is kept on a separate DLL that accepts partial callers and wraps objects from my other assemblies for IPy, this seems to fit all of my requirements. So I guess my question is, Is that option just beyond the scope of a simple IPy hosting scenario? I want to release the static class I'm using to manage the engine\runtime setup and I want to know if I should be allowing the option of externally rebuilding the sandboxed appDomain with user-specified trusted assemblies. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Wed Oct 22 22:24:10 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 22 Oct 2008 21:24:10 +0100 Subject: [IronPython] Silverlight 2 Dynamic Languages SDK Message-ID: <48FF8BEA.2020705@voidspace.org.uk> Hello Jimmy, Will there be a new release of the Silverlight Dynamic Languages SDK for Silverlight 2 - or does the RC version work unmodified? Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From srivatsn at microsoft.com Wed Oct 22 22:56:01 2008 From: srivatsn at microsoft.com (Srivatsn Narayanan) Date: Wed, 22 Oct 2008 13:56:01 -0700 Subject: [IronPython] Announcing IronPython 2.0 Release Candidate 1 Message-ID: Hello IronPython Community, We're pleased to announce the release of IronPython 2.0 Release Candidate 1. We have fixed around 40 bugs since the previous beta. There have been more than 500 bug fixes since the first 2.0 alpha was announced. Apart from the bug fixes these items have also been addressed: - The problem caused by ExtensionAttribute while using IronPython in a .NET 3.5 project that references System.Core has been fixed by moving that type to a new assembly called Microsoft.Scripting.ExtensionAttribute.dll. If you are referencing System.Core you should not reference this assembly while building it but while deploying your application, this assembly needs to be deployed as well. Harry has more details here. - The MSI installer now has an option to ngen the installed binaries. Ngen'ing the dlls gives a significant startup performance boost. The option is turned off by default but if no issues are reported, we'll enable it by default in a future release. - The CPython standard library modules and packages that cannot be imported in IronPython currently have been removed from the MSI installation. The complete list is here - The DLR sample language ToyScript is included in this release in a separate zip file. This is a temporary arrangement till the sample finds a more permanent home. For the references in the ToyScript project to line up, unzip it to the Src folder of the IronPython source release. If no major issues with the RC are reported, we hope to ship the final 2.0 release in around a month's time. Anyone planning to move to 2.0 please try the RC and let us know of any issues you find. These bugs have been closed since the previous release: * 2021 Incorrect __rmul__ invocation for multiplication * 8098 Exceptions not Serializable * 11016 IronPython uses "\r\r\n" as a line separator instead of os.linsep ("\r\n" on Windows) * 11971 Array doesn't have methods w/o importing clr * 14144 time.strftime("%w") bug * 14196 Add __iter__ to items that support IEnumerable but aren't indexable (e.g. Stack) * 15995 Trivial: Different exception thrown by ipy for deque.remove * 16371 DUPLICATE: time.strftime throws a ValueError while CPy doesnt * 16476 Trivial: struct.unpack('I', s) should return int if possible * 16563 Trivial: help(System.DateTime.Parse) * 16693 "yield" in IronPython-2.0B2 broken when yielding global variables * 17355 __contains__ on locals() returns True for globals() when called inside a function * 17740 Relative imports don't work properly when there are two modules with the same name * 17781 Horrible performance regression of exec * 17797 clr.CompileModules is not part of TabCompletion * 17819 DUPLICATE: relative imports don't work inside directory package * 17911 '+' operator no longer supports str and Char as operands * 17963 new.instance(..., None).__dict__ throws a SystemError * 17964 new.instancemethod(someFunction, None) should not be allowed * 18132 New-style classes can't inherit from only old-style classes and use __metaclass__ * 18133 Do not mention IronPython types in the TypeError message emitted from the type function * 18217 CPython's test_socket.py spawns assert windows and hangs * 18312 str(newStyleClass.__dict__) is wrong when there is a recursive reference * 18313 __dict__ of new style classes don't have iteritems(), iterkeys() or itervalues() * 18314 .NET Structs that have a default indexer don't support enumeration * 18326 sys.meta_path objects break when relative imports are utilized * 18327 Cannot reload modules which are created by objects in sys.path_hooks * 18331 unicode('\\', 'raw_unicode_escape') throws an error * 18333 decoding of 'unicode_internal' strings is broken * 18350 Innacuracy in float representation (causing pickle problems) * 18517 -X:ExceptionDetail behaves differently depending upon the OS (or CLR minor version) * 18523 Case insensitive ipy.exe tab completion broken * 18524 COM methods don't work on x64 platforms * 18575 Compiling modules with cyclic imports inside a package fails * 18576 compiling a package with sub-packages doesnt preserve the hierarchy. * 18639 COM methods can't correctly be used as Python dict keys under -X:PreferComInteropAssembly * 18728 hmac module broken * 18747 Regular expression repeat qualifier {m,n} does not work if lower bound is omitted We'd like to thank everyone in the community who reported these bugs: sanxiyn, Michael Foord, jtenney, yanne, zpy, atifaziz, srid, Eloff, Korbinian, sdahlbac and baxeno. These bugs were reported internally and closed: * 409568 test_parrot fails under -X:Interpret (Debug binaries on 64-bit platforms) w/ StackOverflowException * 436524 __perf_getmember.py broken by merged SNAP job (changeset 435597) * 497193 tf changeset 533300 caused 60% perf degrade in IronPython startup time You can download IronPython 2.0 RC1 at: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=17404 The IronPython Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From dfugate at microsoft.com Wed Oct 22 23:57:47 2008 From: dfugate at microsoft.com (Dave Fugate) Date: Wed, 22 Oct 2008 14:57:47 -0700 Subject: [IronPython] Announcing IronPython 2.0 Release Candidate 1 - Documentation In-Reply-To: References: Message-ID: This is just a small note that the IronPython Team is aware of the fact that most IronPython documentation (e.g., Tutorial, readme, etc) included in IP 2.0RC1 is out of date with respect to IP 2.0. We'll be spending the next couple of weeks revising this and working on the samples assuming no major issues are discovered in RC1. Thanks, The IronPython Team From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Srivatsn Narayanan Sent: Wednesday, October 22, 2008 1:56 PM To: Discussion of IronPython Subject: [IronPython] Announcing IronPython 2.0 Release Candidate 1 Hello IronPython Community, We're pleased to announce the release of IronPython 2.0 Release Candidate 1. We have fixed around 40 bugs since the previous beta. There have been more than 500 bug fixes since the first 2.0 alpha was announced. Apart from the bug fixes these items have also been addressed: - The problem caused by ExtensionAttribute while using IronPython in a .NET 3.5 project that references System.Core has been fixed by moving that type to a new assembly called Microsoft.Scripting.ExtensionAttribute.dll. If you are referencing System.Core you should not reference this assembly while building it but while deploying your application, this assembly needs to be deployed as well. Harry has more details here. - The MSI installer now has an option to ngen the installed binaries. Ngen'ing the dlls gives a significant startup performance boost. The option is turned off by default but if no issues are reported, we'll enable it by default in a future release. - The CPython standard library modules and packages that cannot be imported in IronPython currently have been removed from the MSI installation. The complete list is here - The DLR sample language ToyScript is included in this release in a separate zip file. This is a temporary arrangement till the sample finds a more permanent home. For the references in the ToyScript project to line up, unzip it to the Src folder of the IronPython source release. If no major issues with the RC are reported, we hope to ship the final 2.0 release in around a month's time. Anyone planning to move to 2.0 please try the RC and let us know of any issues you find. These bugs have been closed since the previous release: * 2021 Incorrect __rmul__ invocation for multiplication * 8098 Exceptions not Serializable * 11016 IronPython uses "\r\r\n" as a line separator instead of os.linsep ("\r\n" on Windows) * 11971 Array doesn't have methods w/o importing clr * 14144 time.strftime("%w") bug * 14196 Add __iter__ to items that support IEnumerable but aren't indexable (e.g. Stack) * 15995 Trivial: Different exception thrown by ipy for deque.remove * 16371 DUPLICATE: time.strftime throws a ValueError while CPy doesnt * 16476 Trivial: struct.unpack('I', s) should return int if possible * 16563 Trivial: help(System.DateTime.Parse) * 16693 "yield" in IronPython-2.0B2 broken when yielding global variables * 17355 __contains__ on locals() returns True for globals() when called inside a function * 17740 Relative imports don't work properly when there are two modules with the same name * 17781 Horrible performance regression of exec * 17797 clr.CompileModules is not part of TabCompletion * 17819 DUPLICATE: relative imports don't work inside directory package * 17911 '+' operator no longer supports str and Char as operands * 17963 new.instance(..., None).__dict__ throws a SystemError * 17964 new.instancemethod(someFunction, None) should not be allowed * 18132 New-style classes can't inherit from only old-style classes and use __metaclass__ * 18133 Do not mention IronPython types in the TypeError message emitted from the type function * 18217 CPython's test_socket.py spawns assert windows and hangs * 18312 str(newStyleClass.__dict__) is wrong when there is a recursive reference * 18313 __dict__ of new style classes don't have iteritems(), iterkeys() or itervalues() * 18314 .NET Structs that have a default indexer don't support enumeration * 18326 sys.meta_path objects break when relative imports are utilized * 18327 Cannot reload modules which are created by objects in sys.path_hooks * 18331 unicode('\\', 'raw_unicode_escape') throws an error * 18333 decoding of 'unicode_internal' strings is broken * 18350 Innacuracy in float representation (causing pickle problems) * 18517 -X:ExceptionDetail behaves differently depending upon the OS (or CLR minor version) * 18523 Case insensitive ipy.exe tab completion broken * 18524 COM methods don't work on x64 platforms * 18575 Compiling modules with cyclic imports inside a package fails * 18576 compiling a package with sub-packages doesnt preserve the hierarchy. * 18639 COM methods can't correctly be used as Python dict keys under -X:PreferComInteropAssembly * 18728 hmac module broken * 18747 Regular expression repeat qualifier {m,n} does not work if lower bound is omitted We'd like to thank everyone in the community who reported these bugs: sanxiyn, Michael Foord, jtenney, yanne, zpy, atifaziz, srid, Eloff, Korbinian, sdahlbac and baxeno. These bugs were reported internally and closed: * 409568 test_parrot fails under -X:Interpret (Debug binaries on 64-bit platforms) w/ StackOverflowException * 436524 __perf_getmember.py broken by merged SNAP job (changeset 435597) * 497193 tf changeset 533300 caused 60% perf degrade in IronPython startup time You can download IronPython 2.0 RC1 at: http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=17404 The IronPython Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jimmy.Schementi at microsoft.com Thu Oct 23 04:06:28 2008 From: Jimmy.Schementi at microsoft.com (Jimmy Schementi) Date: Wed, 22 Oct 2008 19:06:28 -0700 Subject: [IronPython] Silverlight 2 Dynamic Languages SDK In-Reply-To: <48FF8BEA.2020705@voidspace.org.uk> References: <48FF8BEA.2020705@voidspace.org.uk> Message-ID: <5283CA0A4168DF4FBBD71AE9ECA5A32848A07DA25A@NA-EXMSG-C116.redmond.corp.microsoft.com> Sorry, I didn't announce it on this list, just on twitter. =) It's been updated in place. So sdlsdk-0.4 is the build that works against Silverlight 2 RTW. http://www.codeplex.com/sdlsdk/Release/ProjectReleases.aspx?ReleaseId=17839 ~js > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users- > bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Wednesday, October 22, 2008 1:24 PM > To: Discussion of IronPython > Subject: [IronPython] Silverlight 2 Dynamic Languages SDK > > Hello Jimmy, > > Will there be a new release of the Silverlight Dynamic Languages SDK > for > Silverlight 2 - or does the RC version work unmodified? > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From giles.thomas at resolversystems.com Thu Oct 23 12:02:40 2008 From: giles.thomas at resolversystems.com (Giles Thomas) Date: Thu, 23 Oct 2008 11:02:40 +0100 Subject: [IronPython] Announcing IronPython 2.0 Release Candidate 1 In-Reply-To: References: Message-ID: <49004BC0.3030208@resolversystems.com> Many congratulations to the IP team on this release! We should be able to start the process of properly porting Resolver One to IP 2.0 RC1 in a week or so (we're just finishing off a release of our own), but we've been tracking the betas up until now (as you might have noticed from Michael Foord's emails), so we don't expect any major issues. Of course, if anything does break you'll be the first to know :-) Regards, Giles Srivatsn Narayanan wrote: > > Hello IronPython Community, > > > > We're pleased to announce the release of IronPython 2.0 Release > Candidate 1. We have fixed around 40 bugs since the previous beta. > There have been more than 500 bug fixes since the first 2.0 alpha was > announced. Apart from the bug fixes these items have also been addressed: > > - The problem caused by ExtensionAttribute while using > IronPython in a .NET 3.5 project that references System.Core has been > fixed by moving that type to a new assembly called > Microsoft.Scripting.ExtensionAttribute.dll. If you are referencing > System.Core you should not reference this assembly while building it > but while deploying your application, this assembly needs to be > deployed as well. Harry has more details here > . > > - The MSI installer now has an option to ngen the installed > binaries. Ngen'ing the dlls gives a significant startup performance > boost. The option is turned off by default but if no issues are > reported, we'll enable it by default in a future release. > > - The CPython standard library modules and packages that > cannot be imported in IronPython currently have been removed from the > MSI installation. The complete list is here > > > - The DLR sample language ToyScript is included in this > release in a separate zip file. This is a temporary arrangement till > the sample finds a more permanent home. For the references in the > ToyScript project to line up, unzip it to the Src folder of the > IronPython source release. > > > > If no major issues with the RC are reported, we hope to ship the final > 2.0 release in around a month's time. *Anyone planning to move to 2.0 > please try the RC and let us know of any issues you find.* > > > > These bugs have been closed since the previous release: > > > > ? 2021 Incorrect __rmul__ invocation for > multiplication > > ? 8098 Exceptions not Serializable > > ? 11016 IronPython uses "\r\r\n" as a line separator > instead of os.linsep ("\r\n" on Windows) > > ? 11971 Array doesn't have methods w/o importing clr > > ? 14144 time.strftime("%w") bug > > ? 14196 Add __iter__ to items that support IEnumerable but > aren't indexable (e.g. Stack) > > ? 15995 Trivial: Different exception thrown by ipy for > deque.remove > > ? 16371 DUPLICATE: time.strftime throws a ValueError while > CPy doesnt > > ? 16476 Trivial: struct.unpack('I', s) should return int if > possible > > ? 16563 Trivial: help(System.DateTime.Parse) > > ? 16693 "yield" in IronPython-2.0B2 broken when yielding > global variables > > ? 17355 __contains__ on locals() returns True for globals() > when called inside a function > > ? 17740 Relative imports don't work properly when there are > two modules with the same name > > ? 17781 Horrible performance regression of exec > > ? 17797 clr.CompileModules is not part of > TabCompletion > > ? 17819 DUPLICATE: relative imports don't work inside > directory package > > ? 17911 '+' operator no longer supports str and Char as > operands > > ? 17963 new.instance(..., None).__dict__ throws a > SystemError > > ? 17964 new.instancemethod(someFunction, None) should not > be allowed > > ? 18132 New-style classes can't inherit from only old-style > classes and use __metaclass__ > > ? 18133 Do not mention IronPython types in the TypeError > message emitted from the type function > > ? 18217 CPython's test_socket.py spawns assert windows and > hangs > > ? 18312 str(newStyleClass.__dict__) is wrong when there is > a recursive reference > > ? 18313 __dict__ of new style classes don't have > iteritems(), iterkeys() or itervalues() > > ? 18314 .NET Structs that have a default indexer don't > support enumeration > > ? 18326 sys.meta_path objects break when relative imports > are utilized > > ? 18327 Cannot reload modules which are created by objects > in sys.path_hooks > > ? 18331 unicode('\\', 'raw_unicode_escape') throws an > error > > ? 18333 decoding of 'unicode_internal' strings is > broken > > ? 18350 Innacuracy in float representation (causing pickle > problems) > > ? 18517 -X:ExceptionDetail behaves differently depending > upon the OS (or CLR minor version) > > ? 18523 Case insensitive ipy.exe tab completion > broken > > ? 18524 COM methods don't work on x64 platforms > > ? 18575 Compiling modules with cyclic imports inside a > package fails > > ? 18576 compiling a package with sub-packages doesnt > preserve the hierarchy. > > ? 18639 COM methods can't correctly be used as Python dict > keys under -X:PreferComInteropAssembly > > ? 18728 hmac module broken > > ? 18747 Regular expression repeat qualifier {m,n} does not > work if lower bound is omitted > > > > We'd like to thank everyone in the community who reported these bugs: > sanxiyn, Michael Foord, jtenney, yanne, zpy, atifaziz, srid, Eloff, > Korbinian, sdahlbac and baxeno. > > > > These bugs were reported internally and closed: > > ? 409568 test_parrot fails under -X:Interpret (Debug binaries > on 64-bit platforms) w/ StackOverflowException > > ? 436524 __perf_getmember.py broken by merged SNAP job > (changeset 435597) > > ? 497193 tf changeset 533300 caused 60% perf degrade in > IronPython startup time > > > > You can download IronPython 2.0 RC1 at: > http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=17404 > > > > The IronPython Team > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- Giles Thomas MD & CTO, Resolver Systems Ltd. giles.thomas at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From fernandoacorreia at gmail.com Thu Oct 23 18:56:33 2008 From: fernandoacorreia at gmail.com (Fernando Correia) Date: Thu, 23 Oct 2008 13:56:33 -0300 Subject: [IronPython] Error building ASP.NET 3.5 websites Message-ID: <8140eff40810230956w52c87c58j508111c8ff121305@mail.gmail.com> I'm trying to upgrade from Beta 5 to RC1 and I'm getting, again, errors trying to build an ASP.NET 3.5 website that uses IronPython. The errors are similar to what happened with Beta 1: (0,0): warning CS1685: The predefined type 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\WINDOWS\assembly\GAC_MSIL\System.Core\3.5.0.0__b77a5c561934e089\System.Core.dll' InternalXmlHelper.vb(9,0): error BC30560: 'ExtensionAttribute' is ambiguous in the namespace 'System.Runtime.CompilerServices'. I opened issue 19126 with more details. Regards, Fernando. -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Thu Oct 23 19:03:51 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 23 Oct 2008 10:03:51 -0700 Subject: [IronPython] Error building ASP.NET 3.5 websites In-Reply-To: <8140eff40810230956w52c87c58j508111c8ff121305@mail.gmail.com> References: <8140eff40810230956w52c87c58j508111c8ff121305@mail.gmail.com> Message-ID: Are you explicitly referencing Microsoft.Scripting.ExtensionAttribute.dll? If so, remove that reference from your project. On Thu, Oct 23, 2008 at 9:56 AM, Fernando Correia < fernandoacorreia at gmail.com> wrote: > I'm trying to upgrade from Beta 5 to RC1 and I'm getting, again, errors > trying to build an ASP.NET 3.5 website that uses IronPython. > > The errors are similar to what happened with Beta 1: > > (0,0): warning CS1685: The predefined type > 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in > multiple assemblies in the global alias; using definition from > 'c:\WINDOWS\assembly\GAC_MSIL\System.Core\3.5.0.0__b77a5c561934e089\System.Core.dll' > > InternalXmlHelper.vb(9,0): error BC30560: 'ExtensionAttribute' is ambiguous > in the namespace 'System.Runtime.CompilerServices'. > > I opened issue 19126 with more details. > > Regards, > > Fernando. > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Oct 23 19:16:07 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 23 Oct 2008 18:16:07 +0100 Subject: [IronPython] Silverlight 2 Dynamic Languages SDK In-Reply-To: <5283CA0A4168DF4FBBD71AE9ECA5A32848A07DA25A@NA-EXMSG-C116.redmond.corp.microsoft.com> References: <48FF8BEA.2020705@voidspace.org.uk> <5283CA0A4168DF4FBBD71AE9ECA5A32848A07DA25A@NA-EXMSG-C116.redmond.corp.microsoft.com> Message-ID: <4900B157.2080701@voidspace.org.uk> Jimmy Schementi wrote: > Sorry, I didn't announce it on this list, just on twitter. =) > > It's been updated in place. So sdlsdk-0.4 is the build that works against Silverlight 2 RTW. > > http://www.codeplex.com/sdlsdk/Release/ProjectReleases.aspx?ReleaseId=17839 > > Great! Thanks - time to update the Silverlight chapter of IronPython in Action. Soon be too late for any changes! Michael > ~js > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users- >> bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Wednesday, October 22, 2008 1:24 PM >> To: Discussion of IronPython >> Subject: [IronPython] Silverlight 2 Dynamic Languages SDK >> >> Hello Jimmy, >> >> Will there be a new release of the Silverlight Dynamic Languages SDK >> for >> Silverlight 2 - or does the RC version work unmodified? >> >> Michael >> >> -- >> http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/blog >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From fernandoacorreia at gmail.com Thu Oct 23 19:30:24 2008 From: fernandoacorreia at gmail.com (Fernando Correia) Date: Thu, 23 Oct 2008 14:30:24 -0300 Subject: [IronPython] Error building ASP.NET 3.5 websites In-Reply-To: References: <8140eff40810230956w52c87c58j508111c8ff121305@mail.gmail.com> Message-ID: <8140eff40810231030ic07a4eeg340fd80cd4166de@mail.gmail.com> No, I'm not. The process I followed is described in the issue: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19126 Does the described process work for you? Microsoft.Scripting.ExtensionAttribute.dll is copied to the website's Bin directory without any reference to it (some of the other 4 DLLs is probably referencing it). In as ASP.NET website, if an assembly is in the Bin directory it behaves as a reference. 2008/10/23 Curt Hagenlocher > > Are you explicitly referencing Microsoft.Scripting.ExtensionAttribute.dll? If so, remove that reference from your project. From mbeckius at gmail.com Thu Oct 23 22:30:13 2008 From: mbeckius at gmail.com (Matt Beckius) Date: Thu, 23 Oct 2008 16:30:13 -0400 Subject: [IronPython] Error only from Test Case Message-ID: The test below fails (see stacktrace). If I take the exact same code and execute from a running program,it works just fine. Any suggestions, TIA Matt B. [Test] public void Statements() { var e = new IPEngine(); e.Scope.SetVariable("x","testing"); var script = "import System\nfrom System import *\nx = 'kosher'\nprint 'test'"; e.Execute(script); Assert.AreEqual("kosher",e.Scope.GetVariable("x")); } failed: System.InvalidProgramException : Common Language Runtime detected an invalid program. at Microsoft.Scripting.Actions.MatchCaller.Call6[T0,T1,T2,T3,T4,T5,TRet](Func`8 target, CallSite site, Object[] args) at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) at Microsoft.Scripting.Actions.UpdateDelegates.Update6[T,T0,T1,T2,T3,T4,T5,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5) at IronPython.Runtime.Importer.Import(CodeContext context, String fullName, PythonTuple from, Int32 level) at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext context, String fullName, Int32 level) at $1##1(Closure , Scope , LanguageContext ) at Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression code, Scope scope) at Microsoft.Scripting.ScriptCode.Run(Scope scope) at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink errorSink) at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope) public class IPEngine { #region Member Vars private readonly ScriptEngine engine; private readonly ScriptScope scope; private MemoryStream ms; #endregion Member Vars public IPEngine() { engine = Python.CreateEngine(); engine.ImportModule("clr"); engine.Runtime.LoadAssembly(typeof(System.String).Assembly); scope = Engine.CreateScope(); } public ScriptEngine Engine { get { return engine; } } public ScriptScope Scope { get { return scope; } } public void SetupOutput() { ms = new MemoryStream(); engine.Runtime.IO.SetOutput(ms, Encoding.UTF8); //engine.Runtime.IO.SetErrorOutput(ms, Encoding.UTF8); } /// /// Evaluates a single expressoin /// /// Return Type /// Expressions to Eval /// T public T Eval(string expression) { SetupOutput(); var source = Engine.CreateScriptSourceFromString(expression, SourceCodeKind.Expression); return source.Execute(Scope); } public void Execute(string statements) { SetupOutput(); var source = engine.CreateScriptSourceFromString(statements, SourceCodeKind.Statements); source.Execute(scope); } public string Output { get { using (var sr = new StreamReader(ms)) { ms.Position = 0; return sr.ReadToEnd(); } } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Oct 23 22:38:39 2008 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 23 Oct 2008 13:38:39 -0700 Subject: [IronPython] Error only from Test Case In-Reply-To: References: Message-ID: <350E7D38B6D819428718949920EC23554FF6DC0224@NA-EXMSG-C102.redmond.corp.microsoft.com> Are you using NUnit or NDepend? There's an issue (that we believe is related to how the assemblies are being loaded) which we haven't tracked down just yet: http://www.mail-archive.com/users at lists.ironpython.com/msg07328.html Running the same code outside of NUnit or NDepend should work. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Matt Beckius Sent: Thursday, October 23, 2008 1:30 PM To: users at lists.ironpython.com Subject: [IronPython] Error only from Test Case The test below fails (see stacktrace). If I take the exact same code and execute from a running program,it works just fine. Any suggestions, TIA Matt B. [Test] public void Statements() { var e = new IPEngine(); e.Scope.SetVariable("x","testing"); var script = "import System\nfrom System import *\nx = 'kosher'\nprint 'test'"; e.Execute(script); Assert.AreEqual("kosher",e.Scope.GetVariable("x")); } failed: System.InvalidProgramException : Common Language Runtime detected an invalid program. at Microsoft.Scripting.Actions.MatchCaller.Call6[T0,T1,T2,T3,T4,T5,TRet](Func`8 target, CallSite site, Object[] args) at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) at Microsoft.Scripting.Actions.UpdateDelegates.Update6[T,T0,T1,T2,T3,T4,T5,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5) at IronPython.Runtime.Importer.Import(CodeContext context, String fullName, PythonTuple from, Int32 level) at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext context, String fullName, Int32 level) at $1##1(Closure , Scope , LanguageContext ) at Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression code, Scope scope) at Microsoft.Scripting.ScriptCode.Run(Scope scope) at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink errorSink) at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope) public class IPEngine { #region Member Vars private readonly ScriptEngine engine; private readonly ScriptScope scope; private MemoryStream ms; #endregion Member Vars public IPEngine() { engine = Python.CreateEngine(); engine.ImportModule("clr"); engine.Runtime.LoadAssembly(typeof(System.String).Assembly); scope = Engine.CreateScope(); } public ScriptEngine Engine { get { return engine; } } public ScriptScope Scope { get { return scope; } } public void SetupOutput() { ms = new MemoryStream(); engine.Runtime.IO.SetOutput(ms, Encoding.UTF8); //engine.Runtime.IO.SetErrorOutput(ms, Encoding.UTF8); } /// /// Evaluates a single expressoin /// /// Return Type /// Expressions to Eval /// T public T Eval(string expression) { SetupOutput(); var source = Engine.CreateScriptSourceFromString(expression, SourceCodeKind.Expression); return source.Execute(Scope); } public void Execute(string statements) { SetupOutput(); var source = engine.CreateScriptSourceFromString(statements, SourceCodeKind.Statements); source.Execute(scope); } public string Output { get { using (var sr = new StreamReader(ms)) { ms.Position = 0; return sr.ReadToEnd(); } } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbeckius at gmail.com Thu Oct 23 22:46:50 2008 From: mbeckius at gmail.com (Matt Beckius) Date: Thu, 23 Oct 2008 16:46:50 -0400 Subject: [IronPython] Error only from Test Case In-Reply-To: <350E7D38B6D819428718949920EC23554FF6DC0224@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <350E7D38B6D819428718949920EC23554FF6DC0224@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: We're NUnit and TypeMock. On Thu, Oct 23, 2008 at 4:38 PM, Dino Viehland wrote: > Are you using NUnit or NDepend? There's an issue (that we believe is > related to how the assemblies are being loaded) which we haven't tracked > down just yet: > http://www.mail-archive.com/users at lists.ironpython.com/msg07328.html > > > > Running the same code outside of NUnit or NDepend should work. > > > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Matt Beckius > *Sent:* Thursday, October 23, 2008 1:30 PM > *To:* users at lists.ironpython.com > *Subject:* [IronPython] Error only from Test Case > > > > The test below fails (see stacktrace). If I take the exact same code and > execute from a running program,it works just fine. > > Any suggestions, > > > > TIA > > > > Matt B. > > > > [Test] > > public void Statements() > > { > > var e = new IPEngine(); > > e.Scope.SetVariable("x","testing"); > > var script = "import System\nfrom System import *\nx = > 'kosher'\nprint 'test'"; > > e.Execute(script); > > Assert.AreEqual("kosher",e.Scope.GetVariable("x")); > > } > > > > > > failed: System.InvalidProgramException : Common Language Runtime detected > an invalid program. > > at > Microsoft.Scripting.Actions.MatchCaller.Call6[T0,T1,T2,T3,T4,T5,TRet](Func`8 > target, CallSite site, Object[] args) > > at > Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) > > at > Microsoft.Scripting.Actions.UpdateDelegates.Update6[T,T0,T1,T2,T3,T4,T5,TRet](CallSite > site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5) > > at IronPython.Runtime.Importer.Import(CodeContext context, > String fullName, PythonTuple from, Int32 level) > > at > IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext context, > String fullName, Int32 level) > > at $1##1(Closure , Scope , LanguageContext ) > > at > Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression > code, Scope scope) > > at Microsoft.Scripting.ScriptCode.Run(Scope scope) > > at Microsoft.Scripting.SourceUnit.Execute(Scope scope, > ErrorSink errorSink) > > at > Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope) > > > > public class IPEngine > > { > > #region Member Vars > > > > private readonly ScriptEngine engine; > > private readonly ScriptScope scope; > > private MemoryStream ms; > > > > #endregion Member Vars > > > > public IPEngine() > > { > > engine = Python.CreateEngine(); > > engine.ImportModule("clr"); > > engine.Runtime.LoadAssembly(typeof(System.String).Assembly); > > scope = Engine.CreateScope(); > > } > > > > public ScriptEngine Engine > > { > > get { return engine; } > > } > > > > public ScriptScope Scope > > { > > get { return scope; } > > } > > > > public void SetupOutput() > > { > > ms = new MemoryStream(); > > engine.Runtime.IO.SetOutput(ms, Encoding.UTF8); > > //engine.Runtime.IO.SetErrorOutput(ms, Encoding.UTF8); > > } > > > > /// > > /// Evaluates a single expressoin > > /// > > /// Return Type > > /// Expressions to Eval > > /// T > > public T Eval(string expression) > > { > > SetupOutput(); > > var source = Engine.CreateScriptSourceFromString(expression, > SourceCodeKind.Expression); > > return source.Execute(Scope); > > } > > > > public void Execute(string statements) > > { > > SetupOutput(); > > var source = engine.CreateScriptSourceFromString(statements, > SourceCodeKind.Statements); > > source.Execute(scope); > > } > > > > public string Output > > { > > get > > { > > using (var sr = new StreamReader(ms)) > > { > > ms.Position = 0; > > return sr.ReadToEnd(); > > } > > } > > } > > } > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Thu Oct 23 23:00:20 2008 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 23 Oct 2008 14:00:20 -0700 Subject: [IronPython] Error only from Test Case In-Reply-To: References: <350E7D38B6D819428718949920EC23554FF6DC0224@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <350E7D38B6D819428718949920EC23554FF6DC0246@NA-EXMSG-C102.redmond.corp.microsoft.com> Ok, I've opened a work item on CodePlex to track it (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19128). I should have done that last time :) We'll need to investigate this and see what's going on but I think it'll have to wait until after 2.0 at this point. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Matt Beckius Sent: Thursday, October 23, 2008 1:47 PM To: Discussion of IronPython Subject: Re: [IronPython] Error only from Test Case We're NUnit and TypeMock. On Thu, Oct 23, 2008 at 4:38 PM, Dino Viehland > wrote: Are you using NUnit or NDepend? There's an issue (that we believe is related to how the assemblies are being loaded) which we haven't tracked down just yet: http://www.mail-archive.com/users at lists.ironpython.com/msg07328.html Running the same code outside of NUnit or NDepend should work. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Matt Beckius Sent: Thursday, October 23, 2008 1:30 PM To: users at lists.ironpython.com Subject: [IronPython] Error only from Test Case The test below fails (see stacktrace). If I take the exact same code and execute from a running program,it works just fine. Any suggestions, TIA Matt B. [Test] public void Statements() { var e = new IPEngine(); e.Scope.SetVariable("x","testing"); var script = "import System\nfrom System import *\nx = 'kosher'\nprint 'test'"; e.Execute(script); Assert.AreEqual("kosher",e.Scope.GetVariable("x")); } failed: System.InvalidProgramException : Common Language Runtime detected an invalid program. at Microsoft.Scripting.Actions.MatchCaller.Call6[T0,T1,T2,T3,T4,T5,TRet](Func`8 target, CallSite site, Object[] args) at Microsoft.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) at Microsoft.Scripting.Actions.UpdateDelegates.Update6[T,T0,T1,T2,T3,T4,T5,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5) at IronPython.Runtime.Importer.Import(CodeContext context, String fullName, PythonTuple from, Int32 level) at IronPython.Runtime.Operations.PythonOps.ImportTop(CodeContext context, String fullName, Int32 level) at $1##1(Closure , Scope , LanguageContext ) at Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression code, Scope scope) at Microsoft.Scripting.ScriptCode.Run(Scope scope) at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink errorSink) at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope) public class IPEngine { #region Member Vars private readonly ScriptEngine engine; private readonly ScriptScope scope; private MemoryStream ms; #endregion Member Vars public IPEngine() { engine = Python.CreateEngine(); engine.ImportModule("clr"); engine.Runtime.LoadAssembly(typeof(System.String).Assembly); scope = Engine.CreateScope(); } public ScriptEngine Engine { get { return engine; } } public ScriptScope Scope { get { return scope; } } public void SetupOutput() { ms = new MemoryStream(); engine.Runtime.IO.SetOutput(ms, Encoding.UTF8); //engine.Runtime.IO.SetErrorOutput(ms, Encoding.UTF8); } /// /// Evaluates a single expressoin /// /// Return Type /// Expressions to Eval /// T public T Eval(string expression) { SetupOutput(); var source = Engine.CreateScriptSourceFromString(expression, SourceCodeKind.Expression); return source.Execute(Scope); } public void Execute(string statements) { SetupOutput(); var source = engine.CreateScriptSourceFromString(statements, SourceCodeKind.Statements); source.Execute(scope); } public string Output { get { using (var sr = new StreamReader(ms)) { ms.Position = 0; return sr.ReadToEnd(); } } } } _______________________________________________ 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 xkenneth at gmail.com Fri Oct 24 00:47:48 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Thu, 23 Oct 2008 17:47:48 -0500 Subject: [IronPython] Getting started with IronPython and Silverlight Message-ID: <4EC650FC-2CA9-4604-B93A-537C8C0E3557@gmail.com> All, I'm just getting started with IronPython and Silverlight, and to be honest I have not experience with C#. Are there are any basic tutorials or material that would kick me off on both of these subjects? I've been fiddling with the the SDL-SDK for a little while and I've written some basic examples, but I'm still unsure as to a couple of things. What modules (.Net or otherwise) does the python.dll that's distributed with the sdl-sdk include? Can i extend this? If so, how? Do I have to use it? How do I do basic operations? I've tried using CPython's minidom, which doesn't seem to exist and imports from System.Xml fail. Can I print to the terminal when using Chiron? Can I set pdb traces? I'm currently running the sdl-sdk on OS X ontop of Mono, with pretty good success. Thanks for all the help! Regards, Ken From curt at hagenlocher.org Fri Oct 24 05:16:37 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 23 Oct 2008 20:16:37 -0700 Subject: [IronPython] Error building ASP.NET 3.5 websites In-Reply-To: <8140eff40810231030ic07a4eeg340fd80cd4166de@mail.gmail.com> References: <8140eff40810230956w52c87c58j508111c8ff121305@mail.gmail.com> <8140eff40810231030ic07a4eeg340fd80cd4166de@mail.gmail.com> Message-ID: I'm sorry; the test I performed to verify that this works for a VB web app was faulty. We'll be discussing this at our weekly meeting tomorrow. On Thu, Oct 23, 2008 at 10:30 AM, Fernando Correia < fernandoacorreia at gmail.com> wrote: > No, I'm not. The process I followed is described in the issue: > > http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19126 > > Does the described process work for you? > > Microsoft.Scripting.ExtensionAttribute.dll is copied to the website's > Bin directory without any reference to it (some of the other 4 DLLs is > probably referencing it). In as ASP.NET website, if an assembly is in > the Bin directory it behaves as a reference. > > 2008/10/23 Curt Hagenlocher > > > > Are you explicitly referencing > Microsoft.Scripting.ExtensionAttribute.dll? If so, remove that reference > from your project. > _______________________________________________ > 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 fernandoacorreia at gmail.com Fri Oct 24 11:10:50 2008 From: fernandoacorreia at gmail.com (Fernando Correia) Date: Fri, 24 Oct 2008 06:10:50 -0300 Subject: [IronPython] Error building ASP.NET 3.5 websites In-Reply-To: References: <8140eff40810230956w52c87c58j508111c8ff121305@mail.gmail.com> <8140eff40810231030ic07a4eeg340fd80cd4166de@mail.gmail.com> Message-ID: <8140eff40810240210s69379482y9e4d5c71e07e433e@mail.gmail.com> Thanks, Curt. I understand this is a tricky situation and that the team is trying hard to find a good solution. From fuzzyman at voidspace.org.uk Fri Oct 24 14:32:43 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 24 Oct 2008 13:32:43 +0100 Subject: [IronPython] Getting started with IronPython and Silverlight In-Reply-To: <4EC650FC-2CA9-4604-B93A-537C8C0E3557@gmail.com> References: <4EC650FC-2CA9-4604-B93A-537C8C0E3557@gmail.com> Message-ID: <4901C06B.1010704@voidspace.org.uk> Hello Kenneth, Rob Miles has just made available his book on C# that they use for teaching the first year of computer science at Hull university. No idea what the book is like, but C# is a nice and straightforward language (despite its B&D approach to typing) so it is easy to learn and the book will probably serve you well: http://www.robmiles.com/c-yellow-book/ For IronPython and Silverlight stuff I *highly* recommend IronPython in Action which is apparently an *awesome* wonder of readability and content: http://www.ironpythoninaction.com Other useful resources: * IronPython Cookbook (recipes and examples) http://www.ironpython.info * IronPython URLs (lots of links to IronPython resources) http://ironpython-urls.blogspot.com/ * My IronPython, Silverlight and Winforms tutorials http://www.voidspace.org.uk/ironpython/ All the best, Michael Foord Kenneth Miller wrote: > All, > > I'm just getting started with IronPython and Silverlight, and to > be honest I have not experience with C#. Are there are any basic > tutorials or material that would kick me off on both of these > subjects? I've been fiddling with the the SDL-SDK for a little while > and I've written some basic examples, but I'm still unsure as to a > couple of things. What modules (.Net or otherwise) does the python.dll > that's distributed with the sdl-sdk include? Can i extend this? If so, > how? Do I have to use it? How do I do basic operations? I've tried > using CPython's minidom, which doesn't seem to exist and imports from > System.Xml fail. Can I print to the terminal when using Chiron? Can I > set pdb traces? > > I'm currently running the sdl-sdk on OS X ontop of Mono, with pretty > good success. > > Thanks for all the help! > > Regards, > Ken > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ From MHarelick at ise.com Fri Oct 24 17:38:17 2008 From: MHarelick at ise.com (Harelick, Matthew) Date: Fri, 24 Oct 2008 11:38:17 -0400 Subject: [IronPython] What is stable? Message-ID: Hi: I have tried using the various IDE's associated with Iron Python and I always run into issues, like "Hello world" won't work. If I use just the interpreter, as a python interpreter with .NET extensions, which one is the most stable? I don't want to start using the tool only to discover I ran into some bug because some minor feature is unstable. Thanks Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marty.Nelson at symyx.com Fri Oct 24 17:46:58 2008 From: Marty.Nelson at symyx.com (Marty Nelson) Date: Fri, 24 Oct 2008 08:46:58 -0700 Subject: [IronPython] Getting started with IronPython and Silverlight In-Reply-To: <4901C06B.1010704@voidspace.org.uk> References: <4EC650FC-2CA9-4604-B93A-537C8C0E3557@gmail.com> <4901C06B.1010704@voidspace.org.uk> Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03A7F7B7@srv-be-101.Symyx-IC.symyx.com> Michael - Is "IP in Action" written for IP 2.0? How much is .Net integration and how much is python coding? -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, October 24, 2008 5:33 AM To: Discussion of IronPython Subject: Re: [IronPython] Getting started with IronPython and Silverlight Hello Kenneth, Rob Miles has just made available his book on C# that they use for teaching the first year of computer science at Hull university. No idea what the book is like, but C# is a nice and straightforward language (despite its B&D approach to typing) so it is easy to learn and the book will probably serve you well: http://www.robmiles.com/c-yellow-book/ For IronPython and Silverlight stuff I *highly* recommend IronPython in Action which is apparently an *awesome* wonder of readability and content: http://www.ironpythoninaction.com Other useful resources: * IronPython Cookbook (recipes and examples) http://www.ironpython.info * IronPython URLs (lots of links to IronPython resources) http://ironpython-urls.blogspot.com/ * My IronPython, Silverlight and Winforms tutorials http://www.voidspace.org.uk/ironpython/ All the best, Michael Foord Kenneth Miller wrote: > All, > > I'm just getting started with IronPython and Silverlight, and to > be honest I have not experience with C#. Are there are any basic > tutorials or material that would kick me off on both of these > subjects? I've been fiddling with the the SDL-SDK for a little while > and I've written some basic examples, but I'm still unsure as to a > couple of things. What modules (.Net or otherwise) does the python.dll > that's distributed with the sdl-sdk include? Can i extend this? If so, > how? Do I have to use it? How do I do basic operations? I've tried > using CPython's minidom, which doesn't seem to exist and imports from > System.Xml fail. Can I print to the terminal when using Chiron? Can I > set pdb traces? > > I'm currently running the sdl-sdk on OS X ontop of Mono, with pretty > good success. > > Thanks for all the help! > > Regards, > Ken > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. From fuzzyman at voidspace.org.uk Fri Oct 24 17:54:06 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 24 Oct 2008 16:54:06 +0100 Subject: [IronPython] Getting started with IronPython and Silverlight In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD03A7F7B7@srv-be-101.Symyx-IC.symyx.com> References: <4EC650FC-2CA9-4604-B93A-537C8C0E3557@gmail.com> <4901C06B.1010704@voidspace.org.uk> <515335F32AA04440B3DE6FEA1993E9AD03A7F7B7@srv-be-101.Symyx-IC.symyx.com> Message-ID: <4901EF9E.9060109@voidspace.org.uk> Marty Nelson wrote: > Michael - > > Is "IP in Action" written for IP 2.0? > Yes. > How much is .Net integration and how much is python coding? > > It is a mixture of both. The book aims to be as useful to .NET programmers coming to Python as it is to Python programmers coming to .NET. Chapter 2 is a Python tutorial. Chapter 3 is an introduction to .NET interop including the basic .NET types Chapters 4-6 are on structured IronPython programming - introducing more Python concepts (like lambdas and properties) along with .NET libraries like Windows Forms, System.Xml and so on The rest of the book covers specific topics - testing, advanced Python, tricky corners of .NET interop, Silverlight, databases, ASP.NET, WPF etc. The final two chapters cover writing C# libraries for use from IronPython and embedding IronPython in C#. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, October 24, 2008 5:33 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Getting started with IronPython and > Silverlight > > Hello Kenneth, > > Rob Miles has just made available his book on C# that they use for > teaching the first year of computer science at Hull university. No idea > what the book is like, but C# is a nice and straightforward language > (despite its B&D approach to typing) so it is easy to learn and the book > > will probably serve you well: > > http://www.robmiles.com/c-yellow-book/ > > For IronPython and Silverlight stuff I *highly* recommend IronPython in > Action which is apparently an *awesome* wonder of readability and > content: > > http://www.ironpythoninaction.com > > Other useful resources: > > * IronPython Cookbook (recipes and examples) http://www.ironpython.info > * IronPython URLs (lots of links to IronPython resources) > http://ironpython-urls.blogspot.com/ > * My IronPython, Silverlight and Winforms tutorials > http://www.voidspace.org.uk/ironpython/ > > All the best, > > Michael Foord > > Kenneth Miller wrote: > >> All, >> >> I'm just getting started with IronPython and Silverlight, and to >> be honest I have not experience with C#. Are there are any basic >> tutorials or material that would kick me off on both of these >> subjects? I've been fiddling with the the SDL-SDK for a little while >> and I've written some basic examples, but I'm still unsure as to a >> couple of things. What modules (.Net or otherwise) does the python.dll >> > > >> that's distributed with the sdl-sdk include? Can i extend this? If so, >> > > >> how? Do I have to use it? How do I do basic operations? I've tried >> using CPython's minidom, which doesn't seem to exist and imports from >> System.Xml fail. Can I print to the terminal when using Chiron? Can I >> set pdb traces? >> >> I'm currently running the sdl-sdk on OS X ontop of Mono, with pretty >> good success. >> >> Thanks for all the help! >> >> Regards, >> Ken >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > -- http://www.ironpythoninaction.com/ From fuzzyman at voidspace.org.uk Fri Oct 24 17:57:16 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 24 Oct 2008 16:57:16 +0100 Subject: [IronPython] What is stable? In-Reply-To: References: Message-ID: <4901F05C.3090007@voidspace.org.uk> Harelick, Matthew wrote: > > Hi: > > I have tried using the various IDE?s associated with Iron Python and I > always run into issues, like ?Hello world? won?t work. > Can you be specific? That's a problem I've not heard before. > If I use just the interpreter, as a python interpreter with .NET > extensions, which one is the most stable? > 1.1.2 is the 'official' stable release, but IronPython 2 is now at release candidate (final release aimed for November) and so should be more than stable enough to use. For people coming new to IronPython I would recommend going straight to IronPython 2. Michael Foord > I don?t want to start using the tool only to discover I ran into some > bug because some minor feature is unstable. > > Thanks > > Matthew > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From Marty.Nelson at symyx.com Fri Oct 24 20:28:58 2008 From: Marty.Nelson at symyx.com (Marty Nelson) Date: Fri, 24 Oct 2008 11:28:58 -0700 Subject: [IronPython] Getting started with IronPython and Silverlight In-Reply-To: <4901EF9E.9060109@voidspace.org.uk> References: <4EC650FC-2CA9-4604-B93A-537C8C0E3557@gmail.com> <4901C06B.1010704@voidspace.org.uk><515335F32AA04440B3DE6FEA1993E9AD03A7F7B7@srv-be-101.Symyx-IC.symyx.com> <4901EF9E.9060109@voidspace.org.uk> Message-ID: <515335F32AA04440B3DE6FEA1993E9AD03A7F88F@srv-be-101.Symyx-IC.symyx.com> Great. I was looking for some IronPython books for our developers and testers, I'll order a bunch. When is it going to be available? -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, October 24, 2008 8:54 AM To: Discussion of IronPython Subject: Re: [IronPython] Getting started with IronPython and Silverlight Marty Nelson wrote: > Michael - > > Is "IP in Action" written for IP 2.0? > Yes. > How much is .Net integration and how much is python coding? > > It is a mixture of both. The book aims to be as useful to .NET programmers coming to Python as it is to Python programmers coming to .NET. Chapter 2 is a Python tutorial. Chapter 3 is an introduction to .NET interop including the basic .NET types Chapters 4-6 are on structured IronPython programming - introducing more Python concepts (like lambdas and properties) along with .NET libraries like Windows Forms, System.Xml and so on The rest of the book covers specific topics - testing, advanced Python, tricky corners of .NET interop, Silverlight, databases, ASP.NET, WPF etc. The final two chapters cover writing C# libraries for use from IronPython and embedding IronPython in C#. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, October 24, 2008 5:33 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Getting started with IronPython and > Silverlight > > Hello Kenneth, > > Rob Miles has just made available his book on C# that they use for > teaching the first year of computer science at Hull university. No idea > what the book is like, but C# is a nice and straightforward language > (despite its B&D approach to typing) so it is easy to learn and the book > > will probably serve you well: > > http://www.robmiles.com/c-yellow-book/ > > For IronPython and Silverlight stuff I *highly* recommend IronPython in > Action which is apparently an *awesome* wonder of readability and > content: > > http://www.ironpythoninaction.com > > Other useful resources: > > * IronPython Cookbook (recipes and examples) http://www.ironpython.info > * IronPython URLs (lots of links to IronPython resources) > http://ironpython-urls.blogspot.com/ > * My IronPython, Silverlight and Winforms tutorials > http://www.voidspace.org.uk/ironpython/ > > All the best, > > Michael Foord > > Kenneth Miller wrote: > >> All, >> >> I'm just getting started with IronPython and Silverlight, and to >> be honest I have not experience with C#. Are there are any basic >> tutorials or material that would kick me off on both of these >> subjects? I've been fiddling with the the SDL-SDK for a little while >> and I've written some basic examples, but I'm still unsure as to a >> couple of things. What modules (.Net or otherwise) does the python.dll >> > > >> that's distributed with the sdl-sdk include? Can i extend this? If so, >> > > >> how? Do I have to use it? How do I do basic operations? I've tried >> using CPython's minidom, which doesn't seem to exist and imports from >> System.Xml fail. Can I print to the terminal when using Chiron? Can I >> set pdb traces? >> >> I'm currently running the sdl-sdk on OS X ontop of Mono, with pretty >> good success. >> >> Thanks for all the help! >> >> Regards, >> Ken >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ======= Notice: This e-mail message, together with any attachments, contains information of Symyx Technologies, Inc. or any of its affiliates or subsidiaries that may be confidential, proprietary, copyrighted, privileged and/or protected work product, and is meant solely for the intended recipient. If you are not the intended recipient, and have received this message in error, please contact the sender immediately, permanently delete the original and any copies of this email and any attachments thereto. From phil.vacca at gmail.com Fri Oct 24 21:13:39 2008 From: phil.vacca at gmail.com (Phil Vacca) Date: Fri, 24 Oct 2008 14:13:39 -0500 Subject: [IronPython] Problems with System.DateTime in RC1, and UtcNow in all 2.0 builds Message-ID: <6e2405140810241213q4efc0662oe9a7e7b35be52f14@mail.gmail.com> Hi, I've been using each of the Betas of IPy 2, but now that I've switched to RC1, I've got a probem. The function get_UtcNow() doesn't seem to exist in the RC. Also the UtcNow method seems to have a major problem as well. I am hoping this is related to my own usage, and not to the IPy build! At the interpreter "from System.DateTime import get_UtcNow" fails under the current RC (ipy.exe fileversion 2.0.11020.0), but works fine from beta 5 (ipy.exe fileversion 2.0.10310.5). The error I get reads: File "", line 1, in ImportError: Cannot import name get_UtcNow running "dir( System.DateTime )" shows confirming results. The "get_" functions just don't appear to be in there... So, I tried just using the System.DateTime UtcNow method. Unfortunately, it seems to only work once. By this I mean that it returns the correct time for UtcNow at import, but then every subsequent call returns the SAME initialized time. This behavior is consistent at least against Beta 4 & 5, as well as the RC. I ran the following code at the beta 5 interpreter and got these results: import System from System.DateTime import UtcNow, get_UtcNow def problem(): print UtcNow, get_UtcNow() print long(sum([i for i in range(10000000)])) ## waste some cycles print UtcNow, get_UtcNow() def noProblem(): print System.DateTime.UtcNow, get_UtcNow() print long(sum([i for i in range(10000000)])) ## waste some cycles print System.DateTime.UtcNow, get_UtcNow() >>> problem() 10/24/2008 7:11:21 PM 10/24/2008 7:11:28 PM 49999995000000 10/24/2008 7:11:21 PM 10/24/2008 7:11:32 PM >>> noProblem() 10/24/2008 7:11:43 PM 10/24/2008 7:11:43 PM 49999995000000 10/24/2008 7:11:47 PM 10/24/2008 7:11:47 PM Does anyone else observe this same behavior? -Phil phil.vacca at gmail.com From curt at hagenlocher.org Fri Oct 24 21:55:12 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 24 Oct 2008 12:55:12 -0700 Subject: [IronPython] Problems with System.DateTime in RC1, and UtcNow in all 2.0 builds In-Reply-To: <6e2405140810241213q4efc0662oe9a7e7b35be52f14@mail.gmail.com> References: <6e2405140810241213q4efc0662oe9a7e7b35be52f14@mail.gmail.com> Message-ID: "UtcNow" returns a DateTime, so when you import it into your namespace, you're importing a DateTime instead of some kind of property reference. This is by design. The proper usage is from System import DateTime DateTime.UtcNow This is also consistent with usage under C#. I think the ability to import "get_UtcNow" was a bug that has been fixed for the RC. On Fri, Oct 24, 2008 at 12:13 PM, Phil Vacca wrote: > Hi, > > I've been using each of the Betas of IPy 2, but now that I've switched > to RC1, I've got a probem. The function get_UtcNow() doesn't seem to > exist in the RC. Also the UtcNow method seems to have a major problem > as well. I am hoping this is related to my own usage, and not to the > IPy build! > > At the interpreter "from System.DateTime import get_UtcNow" fails > under the current RC (ipy.exe fileversion 2.0.11020.0), but works fine > from beta 5 (ipy.exe fileversion 2.0.10310.5). > > The error I get reads: > File "", line 1, in > ImportError: Cannot import name get_UtcNow > > running "dir( System.DateTime )" shows confirming results. The "get_" > functions just don't appear to be in there... > > So, I tried just using the System.DateTime UtcNow method. > Unfortunately, it seems to only work once. By this I mean that it > returns the correct time for UtcNow at import, but then every > subsequent call returns the SAME initialized time. This behavior is > consistent at least against Beta 4 & 5, as well as the RC. > > I ran the following code at the beta 5 interpreter and got these results: > import System > from System.DateTime import UtcNow, get_UtcNow > > def problem(): > print UtcNow, get_UtcNow() > print long(sum([i for i in range(10000000)])) ## waste some cycles > print UtcNow, get_UtcNow() > > def noProblem(): > print System.DateTime.UtcNow, get_UtcNow() > print long(sum([i for i in range(10000000)])) ## waste some cycles > print System.DateTime.UtcNow, get_UtcNow() > > >>> problem() > 10/24/2008 7:11:21 PM 10/24/2008 7:11:28 PM > 49999995000000 > 10/24/2008 7:11:21 PM 10/24/2008 7:11:32 PM > >>> noProblem() > 10/24/2008 7:11:43 PM 10/24/2008 7:11:43 PM > 49999995000000 > 10/24/2008 7:11:47 PM 10/24/2008 7:11:47 PM > > Does anyone else observe this same behavior? > > -Phil > > phil.vacca at gmail.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phil.vacca at gmail.com Fri Oct 24 22:57:38 2008 From: phil.vacca at gmail.com (Phil Vacca) Date: Fri, 24 Oct 2008 15:57:38 -0500 Subject: [IronPython] Problems with System.DateTime in RC1, and UtcNow in all 2.0 builds In-Reply-To: References: <6e2405140810241213q4efc0662oe9a7e7b35be52f14@mail.gmail.com> Message-ID: <6e2405140810241357x2676904cm1e5f21d4812e4e06@mail.gmail.com> Many thanks for the quick response! The "get_" functions are only a bug? I guess I have some code to change... -Phil On Fri, Oct 24, 2008 at 2:55 PM, Curt Hagenlocher wrote: > "UtcNow" returns a DateTime, so when you import it into your namespace, > you're importing a DateTime instead of some kind of property reference. > This is by design. The proper usage is > from System import DateTime > DateTime.UtcNow > This is also consistent with usage under C#. > I think the ability to import "get_UtcNow" was a bug that has been fixed for > the RC. From fuzzyman at voidspace.org.uk Sat Oct 25 00:00:13 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 24 Oct 2008 23:00:13 +0100 Subject: [IronPython] Getting started with IronPython and Silverlight In-Reply-To: <515335F32AA04440B3DE6FEA1993E9AD03A7F88F@srv-be-101.Symyx-IC.symyx.com> References: <4EC650FC-2CA9-4604-B93A-537C8C0E3557@gmail.com> <4901C06B.1010704@voidspace.org.uk><515335F32AA04440B3DE6FEA1993E9AD03A7F7B7@srv-be-101.Symyx-IC.symyx.com> <4901EF9E.9060109@voidspace.org.uk> <515335F32AA04440B3DE6FEA1993E9AD03A7F88F@srv-be-101.Symyx-IC.symyx.com> Message-ID: <4902456D.3020509@voidspace.org.uk> Hello Marty, You can get a PDF version through the Manning Early Access Program (MEAP): http://www.manning.com/foord This is the 'still-some-editing-to-come' draft of all 15 chapters (updates to the Silverlight chapter and the last chapter on embedding IronPython plus copy editing still to do). There should be one further update to the MEAP version (probably soon) and then the book itself will come out in January. If you pay for the MEAP you also get the hardcopy version when it comes out. All the best, Michael Marty Nelson wrote: > Great. I was looking for some IronPython books for our developers and > testers, I'll order a bunch. > > When is it going to be available? > > -----Original Message----- > From: users-bounces at lists.ironpython.com > [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, October 24, 2008 8:54 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Getting started with IronPython and > Silverlight > > Marty Nelson wrote: > >> Michael - >> >> Is "IP in Action" written for IP 2.0? >> >> > > Yes. > > >> How much is .Net integration and how much is python coding? >> >> >> > > It is a mixture of both. The book aims to be as useful to .NET > programmers coming to Python as it is to Python programmers coming to > .NET. > > Chapter 2 is a Python tutorial. > Chapter 3 is an introduction to .NET interop including the basic .NET > types > Chapters 4-6 are on structured IronPython programming - introducing more > > Python concepts (like lambdas and properties) along with .NET libraries > like Windows Forms, System.Xml and so on > > The rest of the book covers specific topics - testing, advanced Python, > tricky corners of .NET interop, Silverlight, databases, ASP.NET, WPF > etc. > > The final two chapters cover writing C# libraries for use from > IronPython and embedding IronPython in C#. > > Michael > > > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com >> [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Friday, October 24, 2008 5:33 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] Getting started with IronPython and >> Silverlight >> >> Hello Kenneth, >> >> Rob Miles has just made available his book on C# that they use for >> teaching the first year of computer science at Hull university. No >> > idea > >> what the book is like, but C# is a nice and straightforward language >> (despite its B&D approach to typing) so it is easy to learn and the >> > book > >> will probably serve you well: >> >> http://www.robmiles.com/c-yellow-book/ >> >> For IronPython and Silverlight stuff I *highly* recommend IronPython >> > in > >> Action which is apparently an *awesome* wonder of readability and >> content: >> >> http://www.ironpythoninaction.com >> >> Other useful resources: >> >> * IronPython Cookbook (recipes and examples) >> > http://www.ironpython.info > >> * IronPython URLs (lots of links to IronPython resources) >> http://ironpython-urls.blogspot.com/ >> * My IronPython, Silverlight and Winforms tutorials >> http://www.voidspace.org.uk/ironpython/ >> >> All the best, >> >> Michael Foord >> >> Kenneth Miller wrote: >> >> >>> All, >>> >>> I'm just getting started with IronPython and Silverlight, and to >>> be honest I have not experience with C#. Are there are any basic >>> tutorials or material that would kick me off on both of these >>> subjects? I've been fiddling with the the SDL-SDK for a little while >>> and I've written some basic examples, but I'm still unsure as to a >>> couple of things. What modules (.Net or otherwise) does the >>> > python.dll > >>> >>> >> >> >>> that's distributed with the sdl-sdk include? Can i extend this? If >>> > so, > >>> >>> >> >> >>> how? Do I have to use it? How do I do basic operations? I've tried >>> using CPython's minidom, which doesn't seem to exist and imports from >>> > > >>> System.Xml fail. Can I print to the terminal when using Chiron? Can I >>> > > >>> set pdb traces? >>> >>> I'm currently running the sdl-sdk on OS X ontop of Mono, with pretty >>> good success. >>> >>> Thanks for all the help! >>> >>> Regards, >>> Ken >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >> >> > > > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From curt at hagenlocher.org Sat Oct 25 01:24:51 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 24 Oct 2008 16:24:51 -0700 Subject: [IronPython] Error building ASP.NET 3.5 websites In-Reply-To: <8140eff40810230956w52c87c58j508111c8ff121305@mail.gmail.com> References: <8140eff40810230956w52c87c58j508111c8ff121305@mail.gmail.com> Message-ID: Here's what we recommend as a workaround. The CodePlex work item that tracks this request ( http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19126) now contains a modified version of Microsoft.Scripting.ExtensionAttribute.dll. For this one particular case, where simultaneous referencing of the original version of our assembly and System.Core.dll causes problems, you can replace the "shipping version" of our DLL with the modified version. This will eliminate the "is ambiguous" error message. The magic that makes this work is called "type forwarding". The updated DLL simply contains a type forwarder to System.Core for the type System.Runtime.CompilerServices.ExtensionAttribute. As a result, there is no second copy of that class, and the CLR loader redirects all references from the rest of IronPython to System.Core. This file, though strongly-named and signed, is even more "not supported" than the rest of IronPython :). By this I mean primarily that we haven't run any test passes using the new assembly, and don't plan to. However, as it doesn't actually contain any code, the risks from this modified version should be very small. We hope to address this problem differently for the next release, but our promise to stay compatible with .NET 2.0 for this release has somewhat constrained the type of solution we are able to offer. Thanks for your patience! On Thu, Oct 23, 2008 at 9:56 AM, Fernando Correia < fernandoacorreia at gmail.com> wrote: > I'm trying to upgrade from Beta 5 to RC1 and I'm getting, again, errors > trying to build an ASP.NET 3.5 website that uses IronPython. > > The errors are similar to what happened with Beta 1: > > (0,0): warning CS1685: The predefined type > 'System.Runtime.CompilerServices.ExtensionAttribute' is defined in > multiple assemblies in the global alias; using definition from > 'c:\WINDOWS\assembly\GAC_MSIL\System.Core\3.5.0.0__b77a5c561934e089\System.Core.dll' > > InternalXmlHelper.vb(9,0): error BC30560: 'ExtensionAttribute' is ambiguous > in the namespace 'System.Runtime.CompilerServices'. > > I opened issue 19126 with more details. > > Regards, > > Fernando. > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sun Oct 26 20:49:13 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 26 Oct 2008 19:49:13 +0000 Subject: [IronPython] help on Vista x64 Message-ID: <4904C9B9.1000003@voidspace.org.uk> Hello guys, Using help on methods of .NET types on 32 bit Vista prints useful information. e.g. for help(Stack.Push) >>> help(Stack.Push) Help on method-descriptor Push | Push(...) | Push(self, object obj) | | Inserts an object at the top of the | System.Collections.Stack. | | obj: The System.Object to push onto the | System.Collections.Stack. The value can be null. On Vista x64 it prints: >>> help(Stack.Push) Help on method_descriptor: Push(...) Push(self, object obj) Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From curt at hagenlocher.org Sun Oct 26 21:27:05 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Sun, 26 Oct 2008 13:27:05 -0700 Subject: [IronPython] help on Vista x64 In-Reply-To: <4904C9B9.1000003@voidspace.org.uk> References: <4904C9B9.1000003@voidspace.org.uk> Message-ID: The XML documentation files under the %windir%\Microsoft.NET\Framework directory are not duplicated under %windir%\Microsoft.NET\Framework64 -- that's why we're not finding them. As a workaround, you could probably just copy the files from the one location to the other -- or even create hard links or symbolic links under Vista using "mklink". On Sun, Oct 26, 2008 at 12:49 PM, Michael Foord wrote: > Hello guys, > > Using help on methods of .NET types on 32 bit Vista prints useful > information. e.g. for help(Stack.Push) > > help(Stack.Push) >>>> >>> Help on method-descriptor Push > | Push(...) > | Push(self, object obj) > | > | Inserts an object at the top of the > | System.Collections.Stack. > | > | obj: The System.Object to push onto the > | System.Collections.Stack. The value can be null. > > > On Vista x64 it prints: > > help(Stack.Push) >>>> >>> Help on method_descriptor: > > Push(...) > Push(self, object obj) > > Michael Foord > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Sun Oct 26 21:40:10 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sun, 26 Oct 2008 20:40:10 +0000 Subject: [IronPython] help on Vista x64 In-Reply-To: References: <4904C9B9.1000003@voidspace.org.uk> Message-ID: <4904D5AA.4070407@voidspace.org.uk> Curt Hagenlocher wrote: > The XML documentation files under the %windir%\Microsoft.NET\Framework > directory are not duplicated under %windir%\Microsoft.NET\Framework64 > -- that's why we're not finding them. As a workaround, you could > probably just copy the files from the one location to the other -- or > even create hard links or symbolic links under Vista using "mklink". Where is the code that looks for these XML files? Could it be made to look in the correct place? I'm not looking for a short term workaround but thinking of IronPython users on 64 bit systems (plus I'm not sure if it is too late to document the workaround in my book... :-) Michael > > On Sun, Oct 26, 2008 at 12:49 PM, Michael Foord > > wrote: > > Hello guys, > > Using help on methods of .NET types on 32 bit Vista prints useful > information. e.g. for help(Stack.Push) > > help(Stack.Push) > > Help on method-descriptor Push > | Push(...) > | Push(self, object obj) > | > | Inserts an object at the top of the > | System.Collections.Stack. > | > | obj: The System.Object to push onto the > | System.Collections.Stack. The value can be null. > > > On Vista x64 it prints: > > help(Stack.Push) > > Help on method_descriptor: > > Push(...) > Push(self, object obj) > > Michael Foord > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From curt at hagenlocher.org Sun Oct 26 21:51:41 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Sun, 26 Oct 2008 13:51:41 -0700 Subject: [IronPython] help on Vista x64 In-Reply-To: <4904D5AA.4070407@voidspace.org.uk> References: <4904C9B9.1000003@voidspace.org.uk> <4904D5AA.4070407@voidspace.org.uk> Message-ID: The code is in IronPython\Runtime\Types\DocBuilder.cs. The specific code which translates to an XML file is in "XPathDocument GetXPathDocument(Assembly asm)". In theory, we could say "if the file is not found and the pathname contains 'Framework64', then substitute 'Framework' for 'Framework64' and try again." However, this makes a lot of assumptions about things that are not actually guaranteed by the framework -- and in particular, are not likely to be the same under Mono. On Sun, Oct 26, 2008 at 1:40 PM, Michael Foord wrote: > Curt Hagenlocher wrote: > >> The XML documentation files under the %windir%\Microsoft.NET\Framework >> directory are not duplicated under %windir%\Microsoft.NET\Framework64 -- >> that's why we're not finding them. As a workaround, you could probably just >> copy the files from the one location to the other -- or even create hard >> links or symbolic links under Vista using "mklink". >> > > Where is the code that looks for these XML files? Could it be made to look > in the correct place? > > I'm not looking for a short term workaround but thinking of IronPython > users on 64 bit systems (plus I'm not sure if it is too late to document the > workaround in my book... :-) > > Michael > > >> On Sun, Oct 26, 2008 at 12:49 PM, Michael Foord < >> fuzzyman at voidspace.org.uk > wrote: >> >> Hello guys, >> >> Using help on methods of .NET types on 32 bit Vista prints useful >> information. e.g. for help(Stack.Push) >> >> help(Stack.Push) >> >> Help on method-descriptor Push >> | Push(...) >> | Push(self, object obj) >> | >> | Inserts an object at the top of the >> | System.Collections.Stack. >> | >> | obj: The System.Object to push onto the >> | System.Collections.Stack. The value can be null. >> >> >> On Vista x64 it prints: >> >> help(Stack.Push) >> >> Help on method_descriptor: >> >> Push(...) >> Push(self, object obj) >> >> Michael Foord >> >> -- http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/blog >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > 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 szport at gmail.com Mon Oct 27 08:50:36 2008 From: szport at gmail.com (Zaur Shibzoukhov) Date: Mon, 27 Oct 2008 10:50:36 +0300 Subject: [IronPython] COM Object Issue Message-ID: There is an error in RC 1: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433 Type "help", "copyright", "credits" or "license" for more information. >>> import System >>> wa = System.Activator.CreateInstance(System.Type.GetTypeFromProgID("Word.Application")) >>> wd = wa.Documents.Add() >>> wd.Variables.Add("foo") >>> wd.Variables["foo"] Traceback (most recent call last): File "", line 1, in In IronPython Beta 5 it worked as expected: IronPython 2.0 Beta (2.0.0.5000) on .NET 2.0.50727.1433 Type "help", "copyright", "credits" or "license" for more information. >>> import System >>> wa = System.Activator.CreateInstance(System.Type.GetTypeFromProgID("Word.Application")) >>> wd = wa.Documents.Add() >>> wd.Variables.Add("foo") >>> wd.Variables["foo"] Best regards, Zaur From dinov at microsoft.com Mon Oct 27 15:43:37 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 27 Oct 2008 07:43:37 -0700 Subject: [IronPython] COM Object Issue In-Reply-To: References: Message-ID: <350E7D38B6D819428718949920EC23554FF6DC08FB@NA-EXMSG-C102.redmond.corp.microsoft.com> Is the exception you're seeing "Error while invoking Item"? Just want to make sure I'm seeing the same thing and the actual exception is cut off in your snippet below. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Zaur Shibzoukhov Sent: Monday, October 27, 2008 12:51 AM To: users at lists.ironpython.com Subject: [IronPython] COM Object Issue There is an error in RC 1: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433 Type "help", "copyright", "credits" or "license" for more information. >>> import System >>> wa = System.Activator.CreateInstance(System.Type.GetTypeFromProgID("Word.Application")) >>> wd = wa.Documents.Add() >>> wd.Variables.Add("foo") >>> wd.Variables["foo"] Traceback (most recent call last): File "", line 1, in In IronPython Beta 5 it worked as expected: IronPython 2.0 Beta (2.0.0.5000) on .NET 2.0.50727.1433 Type "help", "copyright", "credits" or "license" for more information. >>> import System >>> wa = System.Activator.CreateInstance(System.Type.GetTypeFromProgID("Word.Application")) >>> wd = wa.Documents.Add() >>> wd.Variables.Add("foo") >>> wd.Variables["foo"] Best regards, Zaur _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Mon Oct 27 15:47:25 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 27 Oct 2008 07:47:25 -0700 Subject: [IronPython] COM Object Issue In-Reply-To: <350E7D38B6D819428718949920EC23554FF6DC08FB@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <350E7D38B6D819428718949920EC23554FF6DC08FB@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <350E7D38B6D819428718949920EC23554FF6DC08FE@NA-EXMSG-C102.redmond.corp.microsoft.com> Oh, and I'm not sure if this is by design or not (I'll need to ping the DLR team), but it seems you can do: wd.Variables.Item('foo') instead. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland Sent: Monday, October 27, 2008 7:44 AM To: Discussion of IronPython Subject: Re: [IronPython] COM Object Issue Is the exception you're seeing "Error while invoking Item"? Just want to make sure I'm seeing the same thing and the actual exception is cut off in your snippet below. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Zaur Shibzoukhov Sent: Monday, October 27, 2008 12:51 AM To: users at lists.ironpython.com Subject: [IronPython] COM Object Issue There is an error in RC 1: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433 Type "help", "copyright", "credits" or "license" for more information. >>> import System >>> wa = System.Activator.CreateInstance(System.Type.GetTypeFromProgID("Word.Application")) >>> wd = wa.Documents.Add() >>> wd.Variables.Add("foo") >>> wd.Variables["foo"] Traceback (most recent call last): File "", line 1, in In IronPython Beta 5 it worked as expected: IronPython 2.0 Beta (2.0.0.5000) on .NET 2.0.50727.1433 Type "help", "copyright", "credits" or "license" for more information. >>> import System >>> wa = System.Activator.CreateInstance(System.Type.GetTypeFromProgID("Word.Application")) >>> wd = wa.Documents.Add() >>> wd.Variables.Add("foo") >>> wd.Variables["foo"] Best regards, Zaur _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From srivatsn at microsoft.com Mon Oct 27 17:33:22 2008 From: srivatsn at microsoft.com (Srivatsn Narayanan) Date: Mon, 27 Oct 2008 09:33:22 -0700 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP Message-ID: Hello IronPython Community, This is a special release of IronPython designed to work with the Visual Studio 2010 CTP. This release will let you try out C# 4.0's new Dynamic feature, which allows you to easily call into dynamic object models such as IronPython modules from your C# code. To get started using IronPython with C#'s Dynamic feature: 1. Install this .MSI on your Visual Studio 2010 CTP Virtual PC image, either by enabling network access or sharing a host folder in Virtual PC's settings. 2. In Visual Studio 2010, click the CTP Walkthroughs link on the Start Page and browse to the Visual Studio walkthroughs. Follow along with the Dynamic Programming in C# walkthrough. This release is not related to the recently released IronPython 2.0 RC1. In fact, this is based on source code from the beta4 timeframe. Also note that this release will only work with the VS10 CTP and not against any other version of .NET. You can download the release here - http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448 The IronPython Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Mon Oct 27 22:31:10 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 27 Oct 2008 14:31:10 -0700 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: References: Message-ID: For those curious about the dynamic feature, here's a code snippet that demonstrates using IronPython from C# 4: ScriptRuntime py = Python.CreateRuntime(); dynamic random = py.UseFile("random.py"); var items = Enumerable.Range(1, 7).ToArray(); random.shuffle(items); (This references the shuffle function in standard Python library file "random.py".) On Mon, Oct 27, 2008 at 9:33 AM, Srivatsn Narayanan wrote: > Hello IronPython Community, > > > > This is a special release of IronPython designed to work with the Visual > Studio 2010 CTP. > This release will let you try out C# 4.0's new Dynamic feature, which allows > you to easily call into dynamic object models such as IronPython modules > from your C# code. > > > > To get started using IronPython with C#'s Dynamic feature: > > 1. Install this .MSIon your Visual Studio 2010 CTP Virtual PC image, either by enabling network > access or sharing a host folder in Virtual PC's settings. > > 2. In Visual Studio 2010, click the *CTP Walkthroughs* link on the > Start Page and browse to the *Visual Studio* walkthroughs. Follow along > with the *Dynamic Programming in C#* walkthrough. > > > > This release is not related to the recently released IronPython 2.0 RC1. In > fact, this is based on source code from the beta4 timeframe. Also note that > this release will only work with the VS10 CTP and not against any other > version of .NET. > > > > You can download the release here - > http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448 > > > > The IronPython Team > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Mon Oct 27 23:02:56 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 28 Oct 2008 00:02:56 +0200 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: References: Message-ID: <8cd017b80810271502x423040cchf575f6e1221aa1ec@mail.gmail.com> Is it me or is C# 4.0 feature list so far is underwhelming? (I know, it's a wrong list) On Mon, Oct 27, 2008 at 6:33 PM, Srivatsn Narayanan wrote: > Hello IronPython Community, > > > > This is a special release of IronPython designed to work with the Visual > Studio 2010 CTP. > This release will let you try out C# 4.0's new Dynamic feature, which allows > you to easily call into dynamic object models such as IronPython modules > from your C# code. > > > > To get started using IronPython with C#'s Dynamic feature: > > 1. Install this .MSIon your Visual Studio 2010 CTP Virtual PC image, either by enabling network > access or sharing a host folder in Virtual PC's settings. > > 2. In Visual Studio 2010, click the *CTP Walkthroughs* link on the > Start Page and browse to the *Visual Studio* walkthroughs. Follow along > with the *Dynamic Programming in C#* walkthrough. > > > > This release is not related to the recently released IronPython 2.0 RC1. In > fact, this is based on source code from the beta4 timeframe. Also note that > this release will only work with the VS10 CTP and not against any other > version of .NET. > > > > You can download the release here - > http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448 > > > > The IronPython Team > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Mon Oct 27 23:12:59 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 28 Oct 2008 00:12:59 +0200 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: <8cd017b80810271502x423040cchf575f6e1221aa1ec@mail.gmail.com> References: <8cd017b80810271502x423040cchf575f6e1221aa1ec@mail.gmail.com> Message-ID: <8cd017b80810271512g4ed94047t81df084fd93a954a@mail.gmail.com> Although it looks like IDynamicObject looks like C# equivalent of method_missing. Now that's something to celebrate. On Tue, Oct 28, 2008 at 12:02 AM, Dody Gunawinata wrote: > Is it me or is C# 4.0 feature list so far is underwhelming? (I know, it's a > wrong list) > > On Mon, Oct 27, 2008 at 6:33 PM, Srivatsn Narayanan < > srivatsn at microsoft.com> wrote: > >> Hello IronPython Community, >> >> >> >> This is a special release of IronPython designed to work with the Visual >> Studio 2010 CTP. >> This release will let you try out C# 4.0's new Dynamic feature, which allows >> you to easily call into dynamic object models such as IronPython modules >> from your C# code. >> >> >> >> To get started using IronPython with C#'s Dynamic feature: >> >> 1. Install this .MSIon your Visual Studio 2010 CTP Virtual PC image, either by enabling network >> access or sharing a host folder in Virtual PC's settings. >> >> 2. In Visual Studio 2010, click the *CTP Walkthroughs* link on the >> Start Page and browse to the *Visual Studio* walkthroughs. Follow along >> with the *Dynamic Programming in C#* walkthrough. >> >> >> >> This release is not related to the recently released IronPython 2.0 RC1. >> In fact, this is based on source code from the beta4 timeframe. Also note >> that this release will only work with the VS10 CTP and not against any other >> version of .NET. >> >> >> >> You can download the release here - >> http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448 >> >> >> >> The IronPython Team >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- > nomadlife.org > > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Mon Oct 27 23:17:06 2008 From: dinov at microsoft.com (Dino Viehland) Date: Mon, 27 Oct 2008 15:17:06 -0700 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: <8cd017b80810271512g4ed94047t81df084fd93a954a@mail.gmail.com> References: <8cd017b80810271502x423040cchf575f6e1221aa1ec@mail.gmail.com> <8cd017b80810271512g4ed94047t81df084fd93a954a@mail.gmail.com> Message-ID: <350E7D38B6D819428718949920EC23554FF6DC0CF1@NA-EXMSG-C102.redmond.corp.microsoft.com> You might find Dynamic / DynamicObject to be more useful for doing simple method-missing style calls. IDynamicObject gives you a lot of power you might not need - but then again you can do some pretty cool things with it too. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata Sent: Monday, October 27, 2008 3:13 PM To: Discussion of IronPython Subject: Re: [IronPython] Announcing IronPython 2.0 VS10 CTP Although it looks like IDynamicObject looks like C# equivalent of method_missing. Now that's something to celebrate. On Tue, Oct 28, 2008 at 12:02 AM, Dody Gunawinata > wrote: Is it me or is C# 4.0 feature list so far is underwhelming? (I know, it's a wrong list) On Mon, Oct 27, 2008 at 6:33 PM, Srivatsn Narayanan > wrote: Hello IronPython Community, This is a special release of IronPython designed to work with the Visual Studio 2010 CTP. This release will let you try out C# 4.0's new Dynamic feature, which allows you to easily call into dynamic object models such as IronPython modules from your C# code. To get started using IronPython with C#'s Dynamic feature: 1. Install this .MSI on your Visual Studio 2010 CTP Virtual PC image, either by enabling network access or sharing a host folder in Virtual PC's settings. 2. In Visual Studio 2010, click the CTP Walkthroughs link on the Start Page and browse to the Visual Studio walkthroughs. Follow along with the Dynamic Programming in C# walkthrough. This release is not related to the recently released IronPython 2.0 RC1. In fact, this is based on source code from the beta4 timeframe. Also note that this release will only work with the VS10 CTP and not against any other version of .NET. You can download the release here - http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448 The IronPython Team _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- nomadlife.org -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Mon Oct 27 23:36:05 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 28 Oct 2008 00:36:05 +0200 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: <350E7D38B6D819428718949920EC23554FF6DC0CF1@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <8cd017b80810271502x423040cchf575f6e1221aa1ec@mail.gmail.com> <8cd017b80810271512g4ed94047t81df084fd93a954a@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF6DC0CF1@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <8cd017b80810271536h36bbc95j9809f657038605f@mail.gmail.com> Yup. It looks like more information needed on all of these dynamic features. In the first glance it looks like C# 4.0 is turning into VB 6 :) On Tue, Oct 28, 2008 at 12:17 AM, Dino Viehland wrote: > You might find Dynamic / DynamicObject to be more useful for doing simple > method-missing style calls. IDynamicObject gives you a lot of power you > might not need ? but then again you can do some pretty cool things with it > too. > > > > *From:* users-bounces at lists.ironpython.com [mailto: > users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata > *Sent:* Monday, October 27, 2008 3:13 PM > *To:* Discussion of IronPython > *Subject:* Re: [IronPython] Announcing IronPython 2.0 VS10 CTP > > > > Although it looks like IDynamicObject looks like C# equivalent of method_missing. > Now that's something to celebrate. > > On Tue, Oct 28, 2008 at 12:02 AM, Dody Gunawinata > wrote: > > Is it me or is C# 4.0 feature list so far is underwhelming? (I know, it's a > wrong list) > > > > > > On Mon, Oct 27, 2008 at 6:33 PM, Srivatsn Narayanan < > srivatsn at microsoft.com> wrote: > > Hello IronPython Community, > > > > This is a special release of IronPython designed to work with the Visual > Studio 2010 CTP. > This release will let you try out C# 4.0's new Dynamic feature, which allows > you to easily call into dynamic object models such as IronPython modules > from your C# code. > > > > To get started using IronPython with C#'s Dynamic feature: > > 1. Install this .MSIon your Visual Studio 2010 CTP Virtual PC image, either by enabling network > access or sharing a host folder in Virtual PC's settings. > > 2. In Visual Studio 2010, click the *CTP Walkthroughs* link on the > Start Page and browse to the *Visual Studio* walkthroughs. Follow along > with the *Dynamic Programming in C#* walkthrough. > > > > This release is not related to the recently released IronPython 2.0 RC1. In > fact, this is based on source code from the beta4 timeframe. Also note that > this release will only work with the VS10 CTP and not against any other > version of .NET. > > > > You can download the release here - > http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448 > > > > The IronPython Team > > > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > nomadlife.org > > > > > -- > nomadlife.org > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Mon Oct 27 23:47:37 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 27 Oct 2008 15:47:37 -0700 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: <8cd017b80810271536h36bbc95j9809f657038605f@mail.gmail.com> References: <8cd017b80810271502x423040cchf575f6e1221aa1ec@mail.gmail.com> <8cd017b80810271512g4ed94047t81df084fd93a954a@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF6DC0CF1@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80810271536h36bbc95j9809f657038605f@mail.gmail.com> Message-ID: Sixteen months ago, Eric Lippert wrote: "Second, this raises the question of whether C# ought to support some of the dynamic features which languages like JScript, Ruby, Python, etc, support. The VB team's motto as far as this question is concerned has always been early binding when possible, late binding when necessary. The C# team, by contrast, has always cleaved to the principle that we do early binding when possible, late binding when the user explicitly writes umpteen dozen of lines of ugly reflection code." [ http://blogs.msdn.com/ericlippert/archive/2007/06/21/calling-static-methods-on-type-variables-is-illegal-part-three.aspx ] Philosophically, this is basically still true -- you have to explicitly opt-in to the dynamic behavior. What's changed is that we've written those "umpteen dozen of lines of ugly reflection code" for you. As for the feature list being underwhelming, there are undoubtedly many people who take the opposite position -- that the language is evolving far too quickly for them to assimilate. And in truth, I can't think of a programming language with C#'s rate of adoption which has evolved as quickly or as radically as C# has. On Mon, Oct 27, 2008 at 3:36 PM, Dody Gunawinata wrote: > Yup. It looks like more information needed on all of these dynamic > features. In the first glance it looks like C# 4.0 is turning into VB 6 :) > > > On Tue, Oct 28, 2008 at 12:17 AM, Dino Viehland wrote: > >> You might find Dynamic / DynamicObject to be more useful for doing >> simple method-missing style calls. IDynamicObject gives you a lot of power >> you might not need ? but then again you can do some pretty cool things with >> it too. >> >> >> >> *From:* users-bounces at lists.ironpython.com [mailto: >> users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata >> *Sent:* Monday, October 27, 2008 3:13 PM >> *To:* Discussion of IronPython >> *Subject:* Re: [IronPython] Announcing IronPython 2.0 VS10 CTP >> >> >> >> Although it looks like IDynamicObject looks like C# equivalent of method_missing. >> Now that's something to celebrate. >> >> On Tue, Oct 28, 2008 at 12:02 AM, Dody Gunawinata < >> empirebuilder at gmail.com> wrote: >> >> Is it me or is C# 4.0 feature list so far is underwhelming? (I know, it's >> a wrong list) >> >> >> >> >> >> On Mon, Oct 27, 2008 at 6:33 PM, Srivatsn Narayanan < >> srivatsn at microsoft.com> wrote: >> >> Hello IronPython Community, >> >> >> >> This is a special release of IronPython designed to work with the Visual >> Studio 2010 CTP. >> This release will let you try out C# 4.0's new Dynamic feature, which allows >> you to easily call into dynamic object models such as IronPython modules >> from your C# code. >> >> >> >> To get started using IronPython with C#'s Dynamic feature: >> >> 1. Install this .MSIon your Visual Studio 2010 CTP Virtual PC image, either by enabling network >> access or sharing a host folder in Virtual PC's settings. >> >> 2. In Visual Studio 2010, click the *CTP Walkthroughs* link on the >> Start Page and browse to the *Visual Studio* walkthroughs. Follow along >> with the *Dynamic Programming in C#* walkthrough. >> >> >> >> This release is not related to the recently released IronPython 2.0 RC1. >> In fact, this is based on source code from the beta4 timeframe. Also note >> that this release will only work with the VS10 CTP and not against any other >> version of .NET. >> >> >> >> You can download the release here - >> http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448 >> >> >> >> The IronPython Team >> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> >> >> -- >> nomadlife.org >> >> >> >> >> -- >> nomadlife.org >> > > > > -- > nomadlife.org > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Tue Oct 28 00:17:33 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 28 Oct 2008 01:17:33 +0200 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: References: <8cd017b80810271502x423040cchf575f6e1221aa1ec@mail.gmail.com> <8cd017b80810271512g4ed94047t81df084fd93a954a@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF6DC0CF1@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80810271536h36bbc95j9809f657038605f@mail.gmail.com> Message-ID: <8cd017b80810271617kbac256dwd6d71eff33ffc7ec@mail.gmail.com> I wonder if this Dynamic Type finally allow heterogeneous data container to be used in C#. This is from the sample code " static void Main(string[] args) { Console.WriteLine("Loading helloworld.py..."); ScriptRuntime py = Python.CreateRuntime(); dynamic helloworld = py.UseFile("helloworld.py"); Console.WriteLine("helloworld.py loaded!"); for (int i = 0; i < 1000; i++) { Console.WriteLine(helloworld.welcome("Employee #{0}"), i); } Console.WriteLine(); }" Now if helloworld actually returns a tuple or mixed typed array, can it actually be used in the C# program? Dody G. On Tue, Oct 28, 2008 at 12:47 AM, Curt Hagenlocher wrote: > Sixteen months ago, Eric Lippert wrote: > "Second, this raises the question of whether C# ought to support some of > the dynamic features which languages like JScript, Ruby, Python, etc, > support. The VB team's motto as far as this question is concerned has always > been early binding when possible, late binding when necessary. The C# team, > by contrast, has always cleaved to the principle that we do early binding > when possible, late binding when the user explicitly writes umpteen dozen of > lines of ugly reflection code." > [ > http://blogs.msdn.com/ericlippert/archive/2007/06/21/calling-static-methods-on-type-variables-is-illegal-part-three.aspx > ] > > Philosophically, this is basically still true -- you have to explicitly > opt-in to the dynamic behavior. What's changed is that we've written those > "umpteen dozen of lines of ugly reflection code" for you. > > > As for the feature list being underwhelming, there are undoubtedly many > people who take the opposite position -- that the language is evolving far > too quickly for them to assimilate. And in truth, I can't think of a > programming language with C#'s rate of adoption which has evolved as quickly > or as radically as C# has. > > > On Mon, Oct 27, 2008 at 3:36 PM, Dody Gunawinata wrote: > >> Yup. It looks like more information needed on all of these dynamic >> features. In the first glance it looks like C# 4.0 is turning into VB 6 :) >> >> >> On Tue, Oct 28, 2008 at 12:17 AM, Dino Viehland wrote: >> >>> You might find Dynamic / DynamicObject to be more useful for doing >>> simple method-missing style calls. IDynamicObject gives you a lot of power >>> you might not need ? but then again you can do some pretty cool things with >>> it too. >>> >>> >>> >>> *From:* users-bounces at lists.ironpython.com [mailto: >>> users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata >>> *Sent:* Monday, October 27, 2008 3:13 PM >>> *To:* Discussion of IronPython >>> *Subject:* Re: [IronPython] Announcing IronPython 2.0 VS10 CTP >>> >>> >>> >>> Although it looks like IDynamicObject looks like C# equivalent of method_missing. >>> Now that's something to celebrate. >>> >>> On Tue, Oct 28, 2008 at 12:02 AM, Dody Gunawinata < >>> empirebuilder at gmail.com> wrote: >>> >>> Is it me or is C# 4.0 feature list so far is underwhelming? (I know, it's >>> a wrong list) >>> >>> >>> >>> >>> >>> On Mon, Oct 27, 2008 at 6:33 PM, Srivatsn Narayanan < >>> srivatsn at microsoft.com> wrote: >>> >>> Hello IronPython Community, >>> >>> >>> >>> This is a special release of IronPython designed to work with the Visual >>> Studio 2010 CTP. >>> This release will let you try out C# 4.0's new Dynamic feature, which allows >>> you to easily call into dynamic object models such as IronPython modules >>> from your C# code. >>> >>> >>> >>> To get started using IronPython with C#'s Dynamic feature: >>> >>> 1. Install this .MSIon your Visual Studio 2010 CTP Virtual PC image, either by enabling network >>> access or sharing a host folder in Virtual PC's settings. >>> >>> 2. In Visual Studio 2010, click the *CTP Walkthroughs* link on the >>> Start Page and browse to the *Visual Studio* walkthroughs. Follow along >>> with the *Dynamic Programming in C#* walkthrough. >>> >>> >>> >>> This release is not related to the recently released IronPython 2.0 RC1. >>> In fact, this is based on source code from the beta4 timeframe. Also note >>> that this release will only work with the VS10 CTP and not against any other >>> version of .NET. >>> >>> >>> >>> You can download the release here - >>> http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448 >>> >>> >>> >>> The IronPython Team >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >>> >>> -- >>> nomadlife.org >>> >>> >>> >>> >>> -- >>> nomadlife.org >>> >> >> >> >> -- >> nomadlife.org >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From timr at probo.com Tue Oct 28 00:52:31 2008 From: timr at probo.com (Tim Roberts) Date: Mon, 27 Oct 2008 16:52:31 -0700 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: References: Message-ID: <4906543F.4060406@probo.com> On Tue, 28 Oct 2008 00:36:05 +0200, "Dody Gunawinata" wrote: > Yup. It looks like more information needed on all of these dynamic features. > In the first glance it looks like C# 4.0 is turning into VB 6 :) > Are you saying that would be a bad thing? Let us recall that VB6 was arguably the most successful release in Visual Basic history. There are still people who won't allow themselves to be dragged away from VB6, more than a decade after its release. -- Tim Roberts, timr at probo.com Providenza & Boekelheide, Inc. From curt at hagenlocher.org Tue Oct 28 01:38:39 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 27 Oct 2008 17:38:39 -0700 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: <8cd017b80810271617kbac256dwd6d71eff33ffc7ec@mail.gmail.com> References: <8cd017b80810271502x423040cchf575f6e1221aa1ec@mail.gmail.com> <8cd017b80810271512g4ed94047t81df084fd93a954a@mail.gmail.com> <350E7D38B6D819428718949920EC23554FF6DC0CF1@NA-EXMSG-C102.redmond.corp.microsoft.com> <8cd017b80810271536h36bbc95j9809f657038605f@mail.gmail.com> <8cd017b80810271617kbac256dwd6d71eff33ffc7ec@mail.gmail.com> Message-ID: List is a heterogenous data container. There's nothing in dynamic typing that is dependent on changes in the underlying CLR code execution engine -- otherwise, we wouldn't be able to ship basically the same DLR for CLR 2 as what's included in CLR 4. Value types still need to be boxed to be treated as "dynamic". Do I misunderstand what you mean? On Mon, Oct 27, 2008 at 4:17 PM, Dody Gunawinata wrote: > I wonder if this Dynamic Type finally allow heterogeneous data container to > be used in C#. > This is from the sample code > " static void Main(string[] args) { > Console.WriteLine("Loading helloworld.py..."); > > ScriptRuntime py = Python.CreateRuntime(); > dynamic helloworld = py.UseFile("helloworld.py"); > > Console.WriteLine("helloworld.py loaded!"); > > > for (int i = 0; i < 1000; i++) > { > Console.WriteLine(helloworld.welcome("Employee #{0}"), i); > } > Console.WriteLine(); > }" > > Now if helloworld actually returns a tuple or mixed typed array, can it > actually be used in the C# program? > > Dody G. > > On Tue, Oct 28, 2008 at 12:47 AM, Curt Hagenlocher wrote: > >> Sixteen months ago, Eric Lippert wrote: >> "Second, this raises the question of whether C# ought to support some of >> the dynamic features which languages like JScript, Ruby, Python, etc, >> support. The VB team's motto as far as this question is concerned has always >> been early binding when possible, late binding when necessary. The C# team, >> by contrast, has always cleaved to the principle that we do early binding >> when possible, late binding when the user explicitly writes umpteen dozen of >> lines of ugly reflection code." >> [ >> http://blogs.msdn.com/ericlippert/archive/2007/06/21/calling-static-methods-on-type-variables-is-illegal-part-three.aspx >> ] >> >> Philosophically, this is basically still true -- you have to explicitly >> opt-in to the dynamic behavior. What's changed is that we've written those >> "umpteen dozen of lines of ugly reflection code" for you. >> >> >> As for the feature list being underwhelming, there are undoubtedly many >> people who take the opposite position -- that the language is evolving far >> too quickly for them to assimilate. And in truth, I can't think of a >> programming language with C#'s rate of adoption which has evolved as quickly >> or as radically as C# has. >> >> >> On Mon, Oct 27, 2008 at 3:36 PM, Dody Gunawinata > > wrote: >> >>> Yup. It looks like more information needed on all of these dynamic >>> features. In the first glance it looks like C# 4.0 is turning into VB 6 :) >>> >>> >>> On Tue, Oct 28, 2008 at 12:17 AM, Dino Viehland wrote: >>> >>>> You might find Dynamic / DynamicObject to be more useful for doing >>>> simple method-missing style calls. IDynamicObject gives you a lot of power >>>> you might not need ? but then again you can do some pretty cool things with >>>> it too. >>>> >>>> >>>> >>>> *From:* users-bounces at lists.ironpython.com [mailto: >>>> users-bounces at lists.ironpython.com] *On Behalf Of *Dody Gunawinata >>>> *Sent:* Monday, October 27, 2008 3:13 PM >>>> *To:* Discussion of IronPython >>>> *Subject:* Re: [IronPython] Announcing IronPython 2.0 VS10 CTP >>>> >>>> >>>> >>>> Although it looks like IDynamicObject looks like C# equivalent of method_missing. >>>> Now that's something to celebrate. >>>> >>>> On Tue, Oct 28, 2008 at 12:02 AM, Dody Gunawinata < >>>> empirebuilder at gmail.com> wrote: >>>> >>>> Is it me or is C# 4.0 feature list so far is underwhelming? (I know, >>>> it's a wrong list) >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Oct 27, 2008 at 6:33 PM, Srivatsn Narayanan < >>>> srivatsn at microsoft.com> wrote: >>>> >>>> Hello IronPython Community, >>>> >>>> >>>> >>>> This is a special release of IronPython designed to work with the Visual >>>> Studio 2010 CTP. >>>> This release will let you try out C# 4.0's new Dynamic feature, which allows >>>> you to easily call into dynamic object models such as IronPython modules >>>> from your C# code. >>>> >>>> >>>> >>>> To get started using IronPython with C#'s Dynamic feature: >>>> >>>> 1. Install this .MSIon your Visual Studio 2010 CTP Virtual PC image, either by enabling network >>>> access or sharing a host folder in Virtual PC's settings. >>>> >>>> 2. In Visual Studio 2010, click the *CTP Walkthroughs* link on >>>> the Start Page and browse to the *Visual Studio* walkthroughs. Follow >>>> along with the *Dynamic Programming in C#* walkthrough. >>>> >>>> >>>> >>>> This release is not related to the recently released IronPython 2.0 RC1. >>>> In fact, this is based on source code from the beta4 timeframe. Also note >>>> that this release will only work with the VS10 CTP and not against any other >>>> version of .NET. >>>> >>>> >>>> >>>> You can download the release here - >>>> http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=18448 >>>> >>>> >>>> >>>> The IronPython Team >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.ironpython.com >>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>>> >>>> >>>> >>>> >>>> -- >>>> nomadlife.org >>>> >>>> >>>> >>>> >>>> -- >>>> nomadlife.org >>>> >>> >>> >>> >>> -- >>> nomadlife.org >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >> > > > -- > nomadlife.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Tue Oct 28 05:32:42 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 28 Oct 2008 06:32:42 +0200 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: <4906543F.4060406@probo.com> References: <4906543F.4060406@probo.com> Message-ID: <8cd017b80810272132y6fb5a37avd4889eed1fa3b6eb@mail.gmail.com> I'd call it missed opportunity if what C# 4.0 dynamic does is only to provide the same facilities that VB6 or VB.Net have provided long time ago. For example, the COM interop thing is nice, but then for the past 8 years you know that if you want to script some Office or COM objects you don't use C# or IronPython or (insert dynamic language). But it looks like there are more here. DynamicObject type and IDynamicObject looks intriguing and I wonder it finally allows more natural XML or ActiveRecord object access via property call like myDocument.Customer.Name.FirstName without resorting to some static code generation. I also wonder if this also allows C# to simulate open classes just by putting a hashtable of object and stuff delegate, data, property into them . Dody G. On Tue, Oct 28, 2008 at 1:52 AM, Tim Roberts wrote: > On Tue, 28 Oct 2008 00:36:05 +0200, "Dody Gunawinata" > wrote: > > Yup. It looks like more information needed on all of these dynamic > features. > > In the first glance it looks like C# 4.0 is turning into VB 6 :) > > > > Are you saying that would be a bad thing? Let us recall that VB6 was > arguably the most successful release in Visual Basic history. There are > still people who won't allow themselves to be dragged away from VB6, > more than a decade after its release. > > -- > Tim Roberts, timr at probo.com > Providenza & Boekelheide, Inc. > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Tue Oct 28 05:58:58 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Mon, 27 Oct 2008 21:58:58 -0700 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: <8cd017b80810272132y6fb5a37avd4889eed1fa3b6eb@mail.gmail.com> References: <4906543F.4060406@probo.com> <8cd017b80810272132y6fb5a37avd4889eed1fa3b6eb@mail.gmail.com> Message-ID: Watch the the videos from the PDC, once they're posted. I know that some of your questions about use of DynamicObject from within C# are answered by Jim Hugunin's talk. Also, if you can download the 23 GB(!) VPC image with the Visual Studio 2010 CTP, you'll be able to try the walkthroughs -- and I think that one specifically addresses the XML scenario. On Mon, Oct 27, 2008 at 9:32 PM, Dody Gunawinata wrote: > I'd call it missed opportunity if what C# 4.0 dynamic does is only to > provide the same facilities that VB6 or VB.Net have provided long time ago. > For example, the COM interop thing is nice, but then for the past 8 years > you know that if you want to script some Office or COM objects you don't use > C# or IronPython or (insert dynamic language). > But it looks like there are more here. DynamicObject type and > IDynamicObject looks intriguing and I wonder it finally allows more natural > XML or ActiveRecord object access via property call > like myDocument.Customer.Name.FirstName without resorting to some static > code generation. I also wonder if this also allows C# to simulate open > classes just by putting a hashtable of object and stuff delegate, data, > property into them . > > > Dody G. > > On Tue, Oct 28, 2008 at 1:52 AM, Tim Roberts wrote: > >> On Tue, 28 Oct 2008 00:36:05 +0200, "Dody Gunawinata" >> wrote: >> > Yup. It looks like more information needed on all of these dynamic >> features. >> > In the first glance it looks like C# 4.0 is turning into VB 6 :) >> > >> >> Are you saying that would be a bad thing? Let us recall that VB6 was >> arguably the most successful release in Visual Basic history. There are >> still people who won't allow themselves to be dragged away from VB6, >> more than a decade after its release. >> >> -- >> Tim Roberts, timr at probo.com >> Providenza & Boekelheide, Inc. >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> > > > > -- > nomadlife.org > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xkenneth at gmail.com Tue Oct 28 06:27:38 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Tue, 28 Oct 2008 00:27:38 -0500 Subject: [IronPython] Current working directory in Silverlight? Message-ID: All, Trying to execute this code in Silverlight: from System.IO import Directory Directory.GetCurrentDirectory() How do I handle directories in silveright? I know it's a bit different since they're packaged. I need to be able to keep track of a file's location inside the package. Thanks for your time. Regards, Ken From fuzzyman at voidspace.org.uk Tue Oct 28 08:57:02 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 28 Oct 2008 07:57:02 +0000 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: <4906543F.4060406@probo.com> References: <4906543F.4060406@probo.com> Message-ID: <4906C5CE.9050704@voidspace.org.uk> Tim Roberts wrote: > On Tue, 28 Oct 2008 00:36:05 +0200, "Dody Gunawinata" > wrote: > >> Yup. It looks like more information needed on all of these dynamic features. >> In the first glance it looks like C# 4.0 is turning into VB 6 :) >> >> > > Are you saying that would be a bad thing? Let us recall that VB6 was > arguably the most successful release in Visual Basic history. There are > still people who won't allow themselves to be dragged away from VB6, > more than a decade after its release. > > I know the lead developer at a successful ASP web development shop. They are still considering whether to upgrade to VB.NET... (ASP.NET offers them nothing compelling he says and porting their huge libraries is made more difficult by the static bindings - unfortunately not using VB.NET is *starting* to cost them business). Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From fuzzyman at voidspace.org.uk Tue Oct 28 12:03:54 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 28 Oct 2008 11:03:54 +0000 Subject: [IronPython] Current working directory in Silverlight? In-Reply-To: References: Message-ID: <4906F19A.6000500@voidspace.org.uk> Kenneth Miller wrote: > All, > > > Trying to execute this code in Silverlight: > > from System.IO import Directory > Directory.GetCurrentDirectory() > What happens when you execute this code? > How do I handle directories in silveright? I know it's a bit > different since they're packaged. I need to be able to keep track of a > file's location inside the package. As you don't have a filesystem in Silverlight I doubt it has a concept of current working directory - this means that you will probably need to track it yourself. Being able to access resources inside the xap file using files is just a convenience. You can also use IsolatedStorage for filesystem like access in browser storage. Michael > > Thanks for your time. > > Regards, > Ken > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From fernandoacorreia at gmail.com Tue Oct 28 12:37:46 2008 From: fernandoacorreia at gmail.com (Fernando Correia) Date: Tue, 28 Oct 2008 08:37:46 -0300 Subject: [IronPython] Error building ASP.NET 3.5 websites In-Reply-To: References: <8140eff40810230956w52c87c58j508111c8ff121305@mail.gmail.com> Message-ID: <8140eff40810280437y20df7c53pb75cfba9c30e4e1b@mail.gmail.com> Thank you, Curt. This workaround allows me to build ASP.NET websites targeting Framework 3.5. I can also build assemblies targeting 3.5. If Microsoft.Scripting.ExtensionAttribute.dll is "The 5th Assembly", what will this alternate version be called? The Ghost Assembly? =D 2008/10/24 Curt Hagenlocher : > Here's what we recommend as a workaround. > The CodePlex work item that tracks this request > (http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19126) now > contains a modified version of Microsoft.Scripting.ExtensionAttribute.dll. > For this one particular case, where simultaneous referencing of the > original version of our assembly and System.Core.dll causes problems, you > can replace the "shipping version" of our DLL with the modified version. > This will eliminate the "is ambiguous" error message. From mikhail.osadnik at realtimeworlds.com Tue Oct 28 15:40:17 2008 From: mikhail.osadnik at realtimeworlds.com (mikhail.osadnik at realtimeworlds.com) Date: Tue, 28 Oct 2008 14:40:17 -0000 Subject: [IronPython] Debugging in VS Expermental Hive Message-ID: Hello A was hoping to get any help on ironpython scripts debugging under Visual Studio 2008 Experimental Hive. The problem is it appears impossible to watch variables in VS IDE .NET debugger apart from the line number ($line) which is somewhat redundant. The setup code is as follows: C# ScriptRuntime Runtime = ScriptRuntime.Create (); Runtime.GlobalOptions.DebugMode = true; Runtime.ExecuteFile ( PyFile ); IronPython import System.Diagnostics System.Diagnostics.Debugger.Break () somevar = 'some string' print somevar So when a breakpoint fires I can go through the IronPython script feeded to ExecuteFile in VS IDE with the debugger. However it appears that plain script's variables in the watch window cannot be resolved. I'd hoped to examine the scope of a script but it turned out that the scope is available only after the ExecuteFile call is done. So the question is - could it be possible to access scope's variables while debugging with VS IDE debugger? IronPython's version I am using is 2.0.0.1000 Cheers Mikhail Osadnik, Senior Software Engineer Realtime Worlds Ltd ____________________________________________________________________ DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xkenneth at gmail.com Tue Oct 28 16:56:07 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Tue, 28 Oct 2008 10:56:07 -0500 Subject: [IronPython] Python Standard Library in IronPython Message-ID: All, I know I can access just about everything in the python standard library by simply adding it to the ironpython path, however this is not a good solution when writing dynamic applications in Silverlight. I can include the standard library with my silverlight application, but this bloats the package and causes horrible load times. I started writing some abstractions last night to do common path operations using whatever library is present (.Net vs cpy) when it dawned on me to simply re-map common functions in the python standard library to the .Net equivalent. Has something like this already been done? If not, does anyone have any interest in doing this? Regards, Ken From dinov at microsoft.com Tue Oct 28 17:22:08 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 28 Oct 2008 09:22:08 -0700 Subject: [IronPython] Debugging in VS Expermental Hive In-Reply-To: References: Message-ID: <350E7D38B6D819428718949920EC23554FF717E9BD@NA-EXMSG-C102.redmond.corp.microsoft.com> Currently you can't see module globals in the debugger but we are working on improving the VS experience. You should be able to see locals that are defined in a function though today. From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of mikhail.osadnik at realtimeworlds.com Sent: Tuesday, October 28, 2008 7:40 AM To: users at lists.ironpython.com Subject: [IronPython] Debugging in VS Expermental Hive Hello A was hoping to get any help on ironpython scripts debugging under Visual Studio 2008 Experimental Hive. The problem is it appears impossible to watch variables in VS IDE .NET debugger apart from the line number ($line) which is somewhat redundant. The setup code is as follows: C# ScriptRuntime Runtime = ScriptRuntime.Create (); Runtime.GlobalOptions.DebugMode = true; Runtime.ExecuteFile ( PyFile ); IronPython import System.Diagnostics System.Diagnostics.Debugger.Break () somevar = 'some string' print somevar So when a breakpoint fires I can go through the IronPython script feeded to ExecuteFile in VS IDE with the debugger. However it appears that plain script's variables in the watch window cannot be resolved. I'd hoped to examine the scope of a script but it turned out that the scope is available only after the ExecuteFile call is done. So the question is - could it be possible to access scope's variables while debugging with VS IDE debugger? IronPython's version I am using is 2.0.0.1000 Cheers Mikhail Osadnik, Senior Software Engineer Realtime Worlds Ltd ____________________________________________________________________ DISCLAIMER This message and any attachments contain privileged and confidential information intended for the use of the addressee named above. If you are not the intended recipient of this message, you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. Please note that we cannot guarantee that this message or any attachment is virus free or that it has not been intercepted and amended. The views of the author may not necessarily reflect those of Realtime Worlds Ltd. Realtime Worlds Ltd is registered in Scotland, number 225628. Registered Office: 152 West Marketgait, Dundee, DD1 1NJ. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Tue Oct 28 19:47:52 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Wed, 29 Oct 2008 03:47:52 +0900 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: References: Message-ID: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> 2008/10/29 Kenneth Miller : > I know I can access just about everything in the python standard library > by simply adding it to the ironpython path, however this is not a good > solution when writing dynamic applications in Silverlight. I can include the > standard library with my silverlight application, but this bloats the > package and causes horrible load times. I started writing some abstractions > last night to do common path operations using whatever library is present > (.Net vs cpy) when it dawned on me to simply re-map common functions in the > python standard library to the .Net equivalent. Has something like this > already been done? If not, does anyone have any interest in doing this? This is a good idea, and I actually planned to do this for path manipulation some time ago, named "clipath" (analogy to "ntpath", "posixpath", etc.). Another obvious candidate is "clidom", reusing .NET's DOM classes. -- Seo Sanghyeon From empirebuilder at gmail.com Tue Oct 28 21:14:48 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 28 Oct 2008 22:14:48 +0200 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: References: <4906543F.4060406@probo.com> <8cd017b80810272132y6fb5a37avd4889eed1fa3b6eb@mail.gmail.com> Message-ID: <8cd017b80810281314s57912e28w7904131be3871737@mail.gmail.com> Hmm..is there any hosted VPC made available? I'm based in Cairo and a 23GB download will probably tie up the whole bandwidth of Africa. Dody G. On Tue, Oct 28, 2008 at 6:58 AM, Curt Hagenlocher wrote: > Watch the the videos from the PDC, once they're posted. I know that some > of your questions about use of DynamicObject from within C# are answered by > Jim Hugunin's talk. Also, if you can download the 23 GB(!) VPC image with > the Visual Studio 2010 CTP, you'll be able to try the walkthroughs -- and I > think that one specifically addresses the XML scenario. > > > On Mon, Oct 27, 2008 at 9:32 PM, Dody Gunawinata wrote: > >> I'd call it missed opportunity if what C# 4.0 dynamic does is only to >> provide the same facilities that VB6 or VB.Net have provided long time ago. >> For example, the COM interop thing is nice, but then for the past 8 years >> you know that if you want to script some Office or COM objects you don't use >> C# or IronPython or (insert dynamic language). >> But it looks like there are more here. DynamicObject type and >> IDynamicObject looks intriguing and I wonder it finally allows more natural >> XML or ActiveRecord object access via property call >> like myDocument.Customer.Name.FirstName without resorting to some static >> code generation. I also wonder if this also allows C# to simulate open >> classes just by putting a hashtable of object and stuff delegate, data, >> property into them . >> >> >> Dody G. >> >> On Tue, Oct 28, 2008 at 1:52 AM, Tim Roberts wrote: >> >>> On Tue, 28 Oct 2008 00:36:05 +0200, "Dody Gunawinata" >>> wrote: >>> > Yup. It looks like more information needed on all of these dynamic >>> features. >>> > In the first glance it looks like C# 4.0 is turning into VB 6 :) >>> > >>> >>> Are you saying that would be a bad thing? Let us recall that VB6 was >>> arguably the most successful release in Visual Basic history. There are >>> still people who won't allow themselves to be dragged away from VB6, >>> more than a decade after its release. >>> >>> -- >>> Tim Roberts, timr at probo.com >>> Providenza & Boekelheide, Inc. >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >> >> >> >> -- >> nomadlife.org >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Tue Oct 28 21:23:56 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 28 Oct 2008 22:23:56 +0200 Subject: [IronPython] IronPython on Intellipad Message-ID: <8cd017b80810281323q3825c928m32e72d2bad99ef3a@mail.gmail.com> The new Oslo technology "Emacs.Net" editor relies on IronPython to do the job that Lisp do for Emacs. "Error Executing Command: 'setmode(MMode)'.Microsoft.Scripting.Runtime.UnboundNameException: name 'setmode' is not defined at IronPython.Runtime.PythonContext.MissingName(SymbolId name) at Microsoft.Scripting.Runtime.LanguageContext.LookupName(CodeContext context, SymbolId name) at Microsoft.Scripting.Runtime.RuntimeHelpers.LookupName(CodeContext context, SymbolId name) at Initialize##97(Closure , CodeContext ) at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean tryEvaluate) at Microsoft.Scripting.ScriptCode.Run(Scope scope) at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink errorSink) at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope) at Microsoft.Intellipad.Scripting.MiniBufferMode.ScriptState.ProcessCommand(String commandText) " -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Tue Oct 28 21:40:58 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 28 Oct 2008 20:40:58 +0000 Subject: [IronPython] IronPython on Intellipad In-Reply-To: <8cd017b80810281323q3825c928m32e72d2bad99ef3a@mail.gmail.com> References: <8cd017b80810281323q3825c928m32e72d2bad99ef3a@mail.gmail.com> Message-ID: <490778DA.9010901@voidspace.org.uk> Dody Gunawinata wrote: > The new Oslo technology "Emacs.Net" editor relies on IronPython to do > the job that Lisp do for Emacs. > What is Emacs.NET ? Michael > > "Error Executing Command: 'setmode(MMode)'. > Microsoft.Scripting.Runtime.UnboundNameException: name 'setmode' is > not defined > at IronPython.Runtime.PythonContext.MissingName(SymbolId name) > at > Microsoft.Scripting.Runtime.LanguageContext.LookupName(CodeContext > context, SymbolId name) > at > Microsoft.Scripting.Runtime.RuntimeHelpers.LookupName(CodeContext > context, SymbolId name) > at Initialize##97(Closure , CodeContext ) > at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, > Boolean tryEvaluate) > at Microsoft.Scripting.ScriptCode.Run(Scope scope) > at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink > errorSink) > at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope) > at > Microsoft.Intellipad.Scripting.MiniBufferMode.ScriptState.ProcessCommand(String > commandText) > " > > -- > nomadlife.org > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From curt at hagenlocher.org Tue Oct 28 21:51:23 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 28 Oct 2008 13:51:23 -0700 Subject: [IronPython] IronPython on Intellipad In-Reply-To: <490778DA.9010901@voidspace.org.uk> References: <8cd017b80810281323q3825c928m32e72d2bad99ef3a@mail.gmail.com> <490778DA.9010901@voidspace.org.uk> Message-ID: That's what the "Connected Systems Division" was publicly calling Intellipad before it had a "real" name. Intellipad is an extensible text editor inspired by Emacs which uses IronPython as its extension language. On Tue, Oct 28, 2008 at 1:40 PM, Michael Foord wrote: > Dody Gunawinata wrote: > >> The new Oslo technology "Emacs.Net" editor relies on IronPython to do the >> job that Lisp do for Emacs. >> > > What is Emacs.NET ? > > Michael > > >> "Error Executing Command: 'setmode(MMode)'. >> Microsoft.Scripting.Runtime.UnboundNameException: name 'setmode' is not >> defined >> at IronPython.Runtime.PythonContext.MissingName(SymbolId name) >> at Microsoft.Scripting.Runtime.LanguageContext.LookupName(CodeContext >> context, SymbolId name) >> at Microsoft.Scripting.Runtime.RuntimeHelpers.LookupName(CodeContext >> context, SymbolId name) >> at Initialize##97(Closure , CodeContext ) >> at Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean >> tryEvaluate) >> at Microsoft.Scripting.ScriptCode.Run(Scope scope) >> at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink >> errorSink) >> at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope scope) >> at >> Microsoft.Intellipad.Scripting.MiniBufferMode.ScriptState.ProcessCommand(String >> commandText) >> " >> >> -- >> nomadlife.org >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Tue Oct 28 21:52:41 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 28 Oct 2008 20:52:41 +0000 Subject: [IronPython] IronPython on Intellipad In-Reply-To: References: <8cd017b80810281323q3825c928m32e72d2bad99ef3a@mail.gmail.com> <490778DA.9010901@voidspace.org.uk> Message-ID: <49077B99.5040001@voidspace.org.uk> Curt Hagenlocher wrote: > That's what the "Connected Systems Division" was publicly calling > Intellipad before it had a "real" name. > > Intellipad is an extensible text editor inspired by Emacs which uses > IronPython as its extension language. Thanks! Michael > > On Tue, Oct 28, 2008 at 1:40 PM, Michael Foord > > wrote: > > Dody Gunawinata wrote: > > The new Oslo technology "Emacs.Net" editor relies on > IronPython to do the job that Lisp do for Emacs. > > > What is Emacs.NET ? > > Michael > > > "Error Executing Command: 'setmode(MMode)'. > Microsoft.Scripting.Runtime.UnboundNameException: name > 'setmode' is not defined > at IronPython.Runtime.PythonContext.MissingName(SymbolId name) > at > Microsoft.Scripting.Runtime.LanguageContext.LookupName(CodeContext > context, SymbolId name) > at > Microsoft.Scripting.Runtime.RuntimeHelpers.LookupName(CodeContext > context, SymbolId name) > at Initialize##97(Closure , CodeContext ) > at Microsoft.Scripting.ScriptCode.Run(CodeContext > codeContext, Boolean tryEvaluate) > at Microsoft.Scripting.ScriptCode.Run(Scope scope) > at Microsoft.Scripting.SourceUnit.Execute(Scope scope, > ErrorSink errorSink) > at > Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope > scope) > at > Microsoft.Intellipad.Scripting.MiniBufferMode.ScriptState.ProcessCommand(String > commandText) > " > > -- > nomadlife.org > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From empirebuilder at gmail.com Tue Oct 28 22:01:16 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 28 Oct 2008 23:01:16 +0200 Subject: [IronPython] IronPython on Intellipad In-Reply-To: <49077B99.5040001@voidspace.org.uk> References: <8cd017b80810281323q3825c928m32e72d2bad99ef3a@mail.gmail.com> <490778DA.9010901@voidspace.org.uk> <49077B99.5040001@voidspace.org.uk> Message-ID: <8cd017b80810281401h3e35ed25hac87956a82438298@mail.gmail.com> It's a WPF editor with IronPython crack :) >From the readme "Customizing commands-------------------- Almost all commands that are available in Intellipad have been written in Python using the object model exposed by the application. The Python files are scattered inside the Settings directory. Commands.py contains most of the commands for Intellipad. Configuration specific commands are placed in their respective directories (Emacs or VI or VisualStudio). A command definition consists of three parts. - A "Executed" function definition, that acts as the command handler and provides the logic for the command - An optional "CanExecute" function definition, that determines when the command is enabled - A command wireup, that is done by calling the Common.Command function. This is the where the Executed and CanExecute are wired together along with the Command Name and default key binding For the moment, a restart is required for the changes to take effect." It's worth downloading. It's 'only' 15MB. Dody G. On Tue, Oct 28, 2008 at 10:52 PM, Michael Foord wrote: > Curt Hagenlocher wrote: > >> That's what the "Connected Systems Division" was publicly calling >> Intellipad before it had a "real" name. >> >> Intellipad is an extensible text editor inspired by Emacs which uses >> IronPython as its extension language. >> > > Thanks! > > Michael > > >> On Tue, Oct 28, 2008 at 1:40 PM, Michael Foord > fuzzyman at voidspace.org.uk>> wrote: >> >> Dody Gunawinata wrote: >> >> The new Oslo technology "Emacs.Net" editor relies on >> IronPython to do the job that Lisp do for Emacs. >> >> >> What is Emacs.NET ? >> >> Michael >> >> >> "Error Executing Command: 'setmode(MMode)'. >> Microsoft.Scripting.Runtime.UnboundNameException: name >> 'setmode' is not defined >> at IronPython.Runtime.PythonContext.MissingName(SymbolId name) >> at >> Microsoft.Scripting.Runtime.LanguageContext.LookupName(CodeContext >> context, SymbolId name) >> at >> Microsoft.Scripting.Runtime.RuntimeHelpers.LookupName(CodeContext >> context, SymbolId name) >> at Initialize##97(Closure , CodeContext ) >> at Microsoft.Scripting.ScriptCode.Run(CodeContext >> codeContext, Boolean tryEvaluate) >> at Microsoft.Scripting.ScriptCode.Run(Scope scope) >> at Microsoft.Scripting.SourceUnit.Execute(Scope scope, >> ErrorSink errorSink) >> at >> Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope >> scope) >> at >> >> Microsoft.Intellipad.Scripting.MiniBufferMode.ScriptState.ProcessCommand(String >> commandText) >> " >> >> -- nomadlife.org < >> http://nomadlife.org> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> >> -- http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/blog >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Tue Oct 28 22:46:22 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 28 Oct 2008 21:46:22 +0000 Subject: [IronPython] IronPython on Intellipad In-Reply-To: <8cd017b80810281401h3e35ed25hac87956a82438298@mail.gmail.com> References: <8cd017b80810281323q3825c928m32e72d2bad99ef3a@mail.gmail.com> <490778DA.9010901@voidspace.org.uk> <49077B99.5040001@voidspace.org.uk> <8cd017b80810281401h3e35ed25hac87956a82438298@mail.gmail.com> Message-ID: <4907882E.4000906@voidspace.org.uk> Do you have a link? Michael Dody Gunawinata wrote: > It's a WPF editor with IronPython crack :) > > From the readme > > "Customizing commands > -------------------- > Almost all commands that are available in Intellipad have been written > in Python using > the object model exposed by the application. The Python files are > scattered inside the > Settings directory. > > Commands.py contains most of the commands for Intellipad. > Configuration specific commands > are placed in their respective directories (Emacs or VI or > VisualStudio). > > A command definition consists of three parts. > - A "Executed" function definition, that acts as the command handler > and provides the > logic for the command > - An optional "CanExecute" function definition, that determines when > the command is > enabled > - A command wireup, that is done by calling the Common.Command > function. This is the > where the Executed and CanExecute are wired together along with the > Command Name and > default key binding > > For the moment, a restart is required for the changes to take effect." > > It's worth downloading. It's 'only' 15MB. > > Dody G. > > On Tue, Oct 28, 2008 at 10:52 PM, Michael Foord > > wrote: > > Curt Hagenlocher wrote: > > That's what the "Connected Systems Division" was publicly > calling Intellipad before it had a "real" name. > > Intellipad is an extensible text editor inspired by Emacs > which uses IronPython as its extension language. > > > Thanks! > > Michael > > > On Tue, Oct 28, 2008 at 1:40 PM, Michael Foord > > >> wrote: > > Dody Gunawinata wrote: > > The new Oslo technology "Emacs.Net" editor relies on > IronPython to do the job that Lisp do for Emacs. > > > What is Emacs.NET ? > > Michael > > > "Error Executing Command: 'setmode(MMode)'. > Microsoft.Scripting.Runtime.UnboundNameException: name > 'setmode' is not defined > at > IronPython.Runtime.PythonContext.MissingName(SymbolId name) > at > > Microsoft.Scripting.Runtime.LanguageContext.LookupName(CodeContext > context, SymbolId name) > at > > Microsoft.Scripting.Runtime.RuntimeHelpers.LookupName(CodeContext > context, SymbolId name) > at Initialize##97(Closure , CodeContext ) > at Microsoft.Scripting.ScriptCode.Run(CodeContext > codeContext, Boolean tryEvaluate) > at Microsoft.Scripting.ScriptCode.Run(Scope scope) > at Microsoft.Scripting.SourceUnit.Execute(Scope scope, > ErrorSink errorSink) > at > > Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope > scope) > at > > Microsoft.Intellipad.Scripting.MiniBufferMode.ScriptState.ProcessCommand(String > commandText) > " > > -- nomadlife.org > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > > > > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > -- http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > > > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > nomadlife.org > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From xkenneth at gmail.com Tue Oct 28 22:53:23 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Tue, 28 Oct 2008 16:53:23 -0500 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> Message-ID: <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> All, >> This is a good idea, and I actually planned to do this for path >> manipulation > some time ago, named "clipath" (analogy to "ntpath", "posixpath", > etc.). > Another obvious candidate is "clidom", reusing .NET's DOM classes. How would these modules be structured, I'd simply just recreate what we need out of the standard library using .NETs classes. So for instance for os.path i'd literally write a new module. I've got the pure python implementation of elementtree along PDIS-XPATH for xpath operations. I've written a few modules here: http://github.com/xkenneth/gpath/tree/master http://github.com/xkenneth/gxml/tree/master I'd like to proceed with this, so why don't we lay some plans out. Regards, Ken > > > -- > Seo Sanghyeon > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Tue Oct 28 22:54:25 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Tue, 28 Oct 2008 23:54:25 +0200 Subject: [IronPython] IronPython on Intellipad In-Reply-To: <4907882E.4000906@voidspace.org.uk> References: <8cd017b80810281323q3825c928m32e72d2bad99ef3a@mail.gmail.com> <490778DA.9010901@voidspace.org.uk> <49077B99.5040001@voidspace.org.uk> <8cd017b80810281401h3e35ed25hac87956a82438298@mail.gmail.com> <4907882E.4000906@voidspace.org.uk> Message-ID: <8cd017b80810281454r5d5224eawb5c8760a98bc2466@mail.gmail.com> http://code.msdn.microsoft.com/oslo/Release/ProjectReleases.aspx?ReleaseId=1707 On Tue, Oct 28, 2008 at 11:46 PM, Michael Foord wrote: > Do you have a link? > > Michael > > Dody Gunawinata wrote: > >> It's a WPF editor with IronPython crack :) >> From the readme >> >> "Customizing commands >> -------------------- >> Almost all commands that are available in Intellipad have been written in >> Python using >> the object model exposed by the application. The Python files are >> scattered inside the >> Settings directory. >> Commands.py contains most of the commands for Intellipad. Configuration >> specific commands >> are placed in their respective directories (Emacs or VI or VisualStudio). >> >> A command definition consists of three parts. - A "Executed" function >> definition, that acts as the command handler and provides the logic for the >> command >> - An optional "CanExecute" function definition, that determines when the >> command is enabled >> - A command wireup, that is done by calling the Common.Command function. >> This is the where the Executed and CanExecute are wired together along >> with the Command Name and >> default key binding >> >> For the moment, a restart is required for the changes to take effect." >> >> It's worth downloading. It's 'only' 15MB. >> >> Dody G. >> >> On Tue, Oct 28, 2008 at 10:52 PM, Michael Foord < >> fuzzyman at voidspace.org.uk > wrote: >> >> Curt Hagenlocher wrote: >> >> That's what the "Connected Systems Division" was publicly >> calling Intellipad before it had a "real" name. >> >> Intellipad is an extensible text editor inspired by Emacs >> which uses IronPython as its extension language. >> >> >> Thanks! >> >> Michael >> >> >> On Tue, Oct 28, 2008 at 1:40 PM, Michael Foord >> >> > >> wrote: >> >> Dody Gunawinata wrote: >> >> The new Oslo technology "Emacs.Net" editor relies on >> IronPython to do the job that Lisp do for Emacs. >> >> >> What is Emacs.NET ? >> >> Michael >> >> >> "Error Executing Command: 'setmode(MMode)'. >> Microsoft.Scripting.Runtime.UnboundNameException: name >> 'setmode' is not defined >> at >> IronPython.Runtime.PythonContext.MissingName(SymbolId name) >> at >> >> Microsoft.Scripting.Runtime.LanguageContext.LookupName(CodeContext >> context, SymbolId name) >> at >> >> Microsoft.Scripting.Runtime.RuntimeHelpers.LookupName(CodeContext >> context, SymbolId name) >> at Initialize##97(Closure , CodeContext ) >> at Microsoft.Scripting.ScriptCode.Run(CodeContext >> codeContext, Boolean tryEvaluate) >> at Microsoft.Scripting.ScriptCode.Run(Scope scope) >> at Microsoft.Scripting.SourceUnit.Execute(Scope scope, >> ErrorSink errorSink) >> at >> >> Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope >> scope) >> at >> >> Microsoft.Intellipad.Scripting.MiniBufferMode.ScriptState.ProcessCommand(String >> commandText) >> " >> >> -- nomadlife.org >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> >> > > >> >> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> -- http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/blog >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> >> > > >> >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> >> -- http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/blog >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> >> >> -- >> nomadlife.org >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Tue Oct 28 23:13:41 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Tue, 28 Oct 2008 15:13:41 -0700 Subject: [IronPython] IronPython on Intellipad In-Reply-To: <8cd017b80810281454r5d5224eawb5c8760a98bc2466@mail.gmail.com> References: <8cd017b80810281323q3825c928m32e72d2bad99ef3a@mail.gmail.com> <490778DA.9010901@voidspace.org.uk> <49077B99.5040001@voidspace.org.uk> <8cd017b80810281401h3e35ed25hac87956a82438298@mail.gmail.com> <4907882E.4000906@voidspace.org.uk> <8cd017b80810281454r5d5224eawb5c8760a98bc2466@mail.gmail.com> Message-ID: See also http://blogs.msdn.com/intellipad On Tue, Oct 28, 2008 at 2:54 PM, Dody Gunawinata wrote: > > http://code.msdn.microsoft.com/oslo/Release/ProjectReleases.aspx?ReleaseId=1707 > > > On Tue, Oct 28, 2008 at 11:46 PM, Michael Foord > wrote: > >> Do you have a link? >> >> Michael >> >> Dody Gunawinata wrote: >> >>> It's a WPF editor with IronPython crack :) >>> >From the readme >>> >>> "Customizing commands >>> -------------------- >>> Almost all commands that are available in Intellipad have been written in >>> Python using >>> the object model exposed by the application. The Python files are >>> scattered inside the >>> Settings directory. >>> Commands.py contains most of the commands for Intellipad. Configuration >>> specific commands >>> are placed in their respective directories (Emacs or VI or VisualStudio). >>> >>> A command definition consists of three parts. - A "Executed" function >>> definition, that acts as the command handler and provides the logic for the >>> command >>> - An optional "CanExecute" function definition, that determines when the >>> command is enabled >>> - A command wireup, that is done by calling the Common.Command function. >>> This is the where the Executed and CanExecute are wired together along >>> with the Command Name and >>> default key binding >>> >>> For the moment, a restart is required for the changes to take effect." >>> >>> It's worth downloading. It's 'only' 15MB. >>> >>> Dody G. >>> >>> On Tue, Oct 28, 2008 at 10:52 PM, Michael Foord < >>> fuzzyman at voidspace.org.uk > wrote: >>> >>> Curt Hagenlocher wrote: >>> >>> That's what the "Connected Systems Division" was publicly >>> calling Intellipad before it had a "real" name. >>> >>> Intellipad is an extensible text editor inspired by Emacs >>> which uses IronPython as its extension language. >>> >>> >>> Thanks! >>> >>> Michael >>> >>> >>> On Tue, Oct 28, 2008 at 1:40 PM, Michael Foord >>> >>> >> >> wrote: >>> >>> Dody Gunawinata wrote: >>> >>> The new Oslo technology "Emacs.Net" editor relies on >>> IronPython to do the job that Lisp do for Emacs. >>> >>> >>> What is Emacs.NET ? >>> >>> Michael >>> >>> >>> "Error Executing Command: 'setmode(MMode)'. >>> Microsoft.Scripting.Runtime.UnboundNameException: name >>> 'setmode' is not defined >>> at >>> IronPython.Runtime.PythonContext.MissingName(SymbolId name) >>> at >>> >>> Microsoft.Scripting.Runtime.LanguageContext.LookupName(CodeContext >>> context, SymbolId name) >>> at >>> >>> Microsoft.Scripting.Runtime.RuntimeHelpers.LookupName(CodeContext >>> context, SymbolId name) >>> at Initialize##97(Closure , CodeContext ) >>> at Microsoft.Scripting.ScriptCode.Run(CodeContext >>> codeContext, Boolean tryEvaluate) >>> at Microsoft.Scripting.ScriptCode.Run(Scope scope) >>> at Microsoft.Scripting.SourceUnit.Execute(Scope scope, >>> ErrorSink errorSink) >>> at >>> >>> Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope >>> scope) >>> at >>> >>> Microsoft.Intellipad.Scripting.MiniBufferMode.ScriptState.ProcessCommand(String >>> commandText) >>> " >>> >>> -- nomadlife.org >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> >>> >> > >>> >>> >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> -- http://www.ironpythoninaction.com/ >>> http://www.voidspace.org.uk/blog >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> >>> >> > >>> >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >>> -- http://www.ironpythoninaction.com/ >>> http://www.voidspace.org.uk/blog >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >>> >>> -- >>> nomadlife.org >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >> >> >> -- >> http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/blog >> >> >> > > > -- > nomadlife.org > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Tue Oct 28 23:19:42 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 28 Oct 2008 22:19:42 +0000 Subject: [IronPython] Error building ASP.NET 3.5 websites In-Reply-To: References: <8140eff40810230956w52c87c58j508111c8ff121305@mail.gmail.com> Message-ID: <49078FFE.20208@voidspace.org.uk> Curt Hagenlocher wrote: [snip...] > We hope to address this problem differently for the next release, but > our promise to stay compatible with .NET 2.0 for this release has > somewhat constrained the type of solution we are able to offer. > Thanks for your patience! > Is there an intention to move away from .NET 2 compatibility with IronPython 2? Michael Foord > On Thu, Oct 23, 2008 at 9:56 AM, Fernando Correia > > wrote: > > I'm trying to upgrade from Beta 5 to RC1 and I'm getting, again, > errors trying to build an ASP.NET 3.5 website > that uses IronPython. > > The errors are similar to what happened with Beta 1: > > (0,0): warning CS1685: The predefined type > 'System.Runtime.CompilerServices.Ex > tensionAttribute' is defined in multiple assemblies in the global > alias; using definition from > 'c:\WINDOWS\assembly\GAC_MSIL\System.Core\3.5.0.0__b77a5c561934e089\System.Core.dll' > > InternalXmlHelper.vb(9,0): error BC30560: 'ExtensionAttribute' is > ambiguous in the namespace 'System.Runtime.CompilerServices'. > > I opened issue 19126 with more details. > > Regards, > > Fernando. > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From dinov at microsoft.com Tue Oct 28 23:28:02 2008 From: dinov at microsoft.com (Dino Viehland) Date: Tue, 28 Oct 2008 15:28:02 -0700 Subject: [IronPython] Error building ASP.NET 3.5 websites In-Reply-To: <49078FFE.20208@voidspace.org.uk> References: <8140eff40810230956w52c87c58j508111c8ff121305@mail.gmail.com> <49078FFE.20208@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23554FF717ED27@NA-EXMSG-C102.redmond.corp.microsoft.com> No - we've briefly spoke about having our 3.0 release be the next version to require a new CLR version and that would be CLR 4 where we get DLR support baked in - but there's nothing concrete yet. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Tuesday, October 28, 2008 3:20 PM To: Discussion of IronPython Subject: Re: [IronPython] Error building ASP.NET 3.5 websites Curt Hagenlocher wrote: [snip...] > We hope to address this problem differently for the next release, but > our promise to stay compatible with .NET 2.0 for this release has > somewhat constrained the type of solution we are able to offer. > Thanks for your patience! > Is there an intention to move away from .NET 2 compatibility with IronPython 2? Michael Foord > On Thu, Oct 23, 2008 at 9:56 AM, Fernando Correia > > wrote: > > I'm trying to upgrade from Beta 5 to RC1 and I'm getting, again, > errors trying to build an ASP.NET 3.5 website > that uses IronPython. > > The errors are similar to what happened with Beta 1: > > (0,0): warning CS1685: The predefined type > 'System.Runtime.CompilerServices.Ex > tensionAttribute' is defined in multiple assemblies in the global > alias; using definition from > 'c:\WINDOWS\assembly\GAC_MSIL\System.Core\3.5.0.0__b77a5c561934e089\System.Core.dll' > > InternalXmlHelper.vb(9,0): error BC30560: 'ExtensionAttribute' is > ambiguous in the namespace 'System.Runtime.CompilerServices'. > > I opened issue 19126 with more details. > > Regards, > > Fernando. > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Tue Oct 28 23:35:36 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Tue, 28 Oct 2008 22:35:36 +0000 Subject: [IronPython] Error building ASP.NET 3.5 websites In-Reply-To: <350E7D38B6D819428718949920EC23554FF717ED27@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <8140eff40810230956w52c87c58j508111c8ff121305@mail.gmail.com> <49078FFE.20208@voidspace.org.uk> <350E7D38B6D819428718949920EC23554FF717ED27@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <490793B8.2010003@voidspace.org.uk> Dino Viehland wrote: > No - we've briefly spoke about having our 3.0 release be the next version to require a new CLR version and that would be CLR 4 where we get DLR support baked in - but there's nothing concrete yet. > Thanks - just checking. :-) Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Tuesday, October 28, 2008 3:20 PM > To: Discussion of IronPython > Subject: Re: [IronPython] Error building ASP.NET 3.5 websites > > Curt Hagenlocher wrote: > [snip...] > >> We hope to address this problem differently for the next release, but >> our promise to stay compatible with .NET 2.0 for this release has >> somewhat constrained the type of solution we are able to offer. >> Thanks for your patience! >> >> > Is there an intention to move away from .NET 2 compatibility with > IronPython 2? > > Michael Foord > > > >> On Thu, Oct 23, 2008 at 9:56 AM, Fernando Correia >> > wrote: >> >> I'm trying to upgrade from Beta 5 to RC1 and I'm getting, again, >> errors trying to build an ASP.NET 3.5 website >> that uses IronPython. >> >> The errors are similar to what happened with Beta 1: >> >> (0,0): warning CS1685: The predefined type >> 'System.Runtime.CompilerServices.Ex >> tensionAttribute' is defined in multiple assemblies in the global >> alias; using definition from >> 'c:\WINDOWS\assembly\GAC_MSIL\System.Core\3.5.0.0__b77a5c561934e089\System.Core.dll' >> >> InternalXmlHelper.vb(9,0): error BC30560: 'ExtensionAttribute' is >> ambiguous in the namespace 'System.Runtime.CompilerServices'. >> >> I opened issue 19126 with more details. >> >> Regards, >> >> Fernando. >> >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From sanxiyn at gmail.com Wed Oct 29 07:16:39 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Wed, 29 Oct 2008 15:16:39 +0900 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> Message-ID: <5b0248170810282316w56e6ec12m22d2e76ec0586b7e@mail.gmail.com> 2008/10/29 Kenneth Miller : > http://github.com/xkenneth/gxml/tree/master What do you think about http://trac.defuze.org/wiki/bridge ? -- Seo Sanghyeon From sanxiyn at gmail.com Wed Oct 29 08:19:25 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Wed, 29 Oct 2008 16:19:25 +0900 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> Message-ID: <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> 2008/10/29 Kenneth Miller : > How would these modules be structured, I'd simply just recreate what we need > out of the standard library using .NETs classes. So for instance for os.path > i'd literally write a new module. I've got the pure python implementation of > elementtree along PDIS-XPATH for xpath operations. I've written a few > modules here: > http://github.com/xkenneth/gpath/tree/master > http://github.com/xkenneth/gxml/tree/master Okay, here is my take on how clipath would be structured: http://www.bitbucket.org/sanxiyn/clipath/ -- Seo Sanghyeon From michael.foord at resolversystems.com Wed Oct 29 13:51:06 2008 From: michael.foord at resolversystems.com (Michael Foord) Date: Wed, 29 Oct 2008 12:51:06 +0000 Subject: [IronPython] Resolver One on IronPython 2 Message-ID: <49085C3A.9000400@resolversystems.com> Hello all, Just a heads-up. Now that IronPython 2 is at the Release Candidate stage we are properly starting the effort to port Resolver One to IronPython 2. Any problems we encounter will be posted here! Resolver One is due for a new release very soon, version 1.3 (which will include the web-server in the non-commercial version for the first time). We aim for a 1.4 release built on IronPython 2 to follow after that. All the best, Michael Foord -- Michael Foord Senior Software Engineer, Resolver Systems Ltd. michael.foord at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From xkenneth at gmail.com Wed Oct 29 16:39:49 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Wed, 29 Oct 2008 10:39:49 -0500 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <5b0248170810282316w56e6ec12m22d2e76ec0586b7e@mail.gmail.com> References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> <5b0248170810282316w56e6ec12m22d2e76ec0586b7e@mail.gmail.com> Message-ID: <94A3CCC9-E0AE-4734-91EC-88EBDA16AD44@gmail.com> Would have used it had I known about it, but it doesn't provide as python of an interface as I'd like, so I think I'll stick with my work for now. Regards, Ken On Oct 29, 2008, at 1:16 AM, Seo Sanghyeon wrote: > 2008/10/29 Kenneth Miller : >> http://github.com/xkenneth/gxml/tree/master > > What do you think about http://trac.defuze.org/wiki/bridge ? > > -- > Seo Sanghyeon > _______________________________________________ > 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 xkenneth at gmail.com Wed Oct 29 16:45:02 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Wed, 29 Oct 2008 10:45:02 -0500 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> Message-ID: <9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com> Seo, Can you give me access to this code? I signed up on bitbucket as xkenneth. Regards, Ken On Oct 29, 2008, at 2:19 AM, Seo Sanghyeon wrote: > 2008/10/29 Kenneth Miller : >> How would these modules be structured, I'd simply just recreate >> what we need >> out of the standard library using .NETs classes. So for instance >> for os.path >> i'd literally write a new module. I've got the pure python >> implementation of >> elementtree along PDIS-XPATH for xpath operations. I've written a few >> modules here: >> http://github.com/xkenneth/gpath/tree/master >> http://github.com/xkenneth/gxml/tree/master > > Okay, here is my take on how clipath would be structured: > http://www.bitbucket.org/sanxiyn/clipath/ > > -- > Seo Sanghyeon > _______________________________________________ > 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 xkenneth at gmail.com Wed Oct 29 16:52:21 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Wed, 29 Oct 2008 10:52:21 -0500 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> Message-ID: Seo, That makes sense to me as well. I want to run python unaltered python scripts on silverlight and (maybe) ironpython without using the python standard library. It makes sense to use the python standard library in IronPython as it's there, and you can use it. However this doesn't make a whole lot of sense in Silverlight for the reasons I mentioned before, mainly bloat. So I suppose we should just rehash what functions we need and build them into an identical structure as found in the standard python libraries? I hope to hear back from you soon! I'm excited to work on a joint project. Regards, Ken On Oct 29, 2008, at 2:19 AM, Seo Sanghyeon wrote: > 2008/10/29 Kenneth Miller : >> How would these modules be structured, I'd simply just recreate >> what we need >> out of the standard library using .NETs classes. So for instance >> for os.path >> i'd literally write a new module. I've got the pure python >> implementation of >> elementtree along PDIS-XPATH for xpath operations. I've written a few >> modules here: >> http://github.com/xkenneth/gpath/tree/master >> http://github.com/xkenneth/gxml/tree/master > > Okay, here is my take on how clipath would be structured: > http://www.bitbucket.org/sanxiyn/clipath/ > > -- > Seo Sanghyeon > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanxiyn at gmail.com Wed Oct 29 17:19:59 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Thu, 30 Oct 2008 01:19:59 +0900 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com> References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> <9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com> Message-ID: <5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com> 2008/10/30 Kenneth Miller : > Seo, > Can you give me access to this code? I signed up on bitbucket as > xkenneth. Done. -- Seo Sanghyeon From aleksander.sumowski at cognifide.com Wed Oct 29 20:11:59 2008 From: aleksander.sumowski at cognifide.com (Aleksander Sumowski) Date: Wed, 29 Oct 2008 20:11:59 +0100 Subject: [IronPython] IronPython 2.0 VS10 CTP installation problems Message-ID: HI! I've just finished downloading VS 10 CTP and now I'm trying to install IronPython on it. The installer stops in the "Please wait while the installer finishes determining your disk space requirements". I've tried installing from command line with logging. The last log entry starts with: Note: 1: 2235 2: 3: ExtendedType 4: SELECT `Act Any hints? Cheers, Aleks -------------- next part -------------- An HTML attachment was scrubbed... URL: From empirebuilder at gmail.com Wed Oct 29 23:38:18 2008 From: empirebuilder at gmail.com (Dody Gunawinata) Date: Thu, 30 Oct 2008 00:38:18 +0200 Subject: [IronPython] Announcing IronPython 2.0 VS10 CTP In-Reply-To: <8cd017b80810281314s57912e28w7904131be3871737@mail.gmail.com> References: <4906543F.4060406@probo.com> <8cd017b80810272132y6fb5a37avd4889eed1fa3b6eb@mail.gmail.com> <8cd017b80810281314s57912e28w7904131be3871737@mail.gmail.com> Message-ID: <8cd017b80810291538o5f5cc993o9bb0778955290734@mail.gmail.com> I think this says it all = Duck Typing, Tuple, Open Class, method_missing .. class C { public dynamic myField; public dynamic MyProp { get; set; } public dynamic MyMethod(dynamic d) { return d.Foo(); } public delegate dynamic MyDelegate(dynamic d); } and this IDynamicObject interface public class MyDynamicObject : IDynamicObject { public MetaObject GetMetaObject(Expression parameter) { return new MyMetaObject(parameter); } } and meta object overrides public class MyMetaObject : MetaObject { public MyMetaObject(Expression parameter) : base(parameter, Restrictions.Empty) { } public override MetaObject Call(CallAction action, MetaObject[] args) { Console.WriteLine("Call of method {0}", action.Name); return this; } public override MetaObject SetMember(SetMemberAction action, MetaObject[] args) { Console.WriteLine("SetMember of property {0}", action.Name); return this; } public override MetaObject GetMember(GetMemberAction action, MetaObject[] args) { Console.WriteLine("GetMember of property {0}", action.Name); return this; } } https://blogs.msdn.com/cburrows/archive/2008/10/28/c-dynamic-part-ii.aspx On Tue, Oct 28, 2008 at 10:14 PM, Dody Gunawinata wrote: > Hmm..is there any hosted VPC made available? I'm based in Cairo and a 23GB > download will probably tie up the whole bandwidth of Africa. > Dody G. > > > On Tue, Oct 28, 2008 at 6:58 AM, Curt Hagenlocher wrote: > >> Watch the the videos from the PDC, once they're posted. I know that some >> of your questions about use of DynamicObject from within C# are answered by >> Jim Hugunin's talk. Also, if you can download the 23 GB(!) VPC image with >> the Visual Studio 2010 CTP, you'll be able to try the walkthroughs -- and I >> think that one specifically addresses the XML scenario. >> >> >> On Mon, Oct 27, 2008 at 9:32 PM, Dody Gunawinata > > wrote: >> >>> I'd call it missed opportunity if what C# 4.0 dynamic does is only to >>> provide the same facilities that VB6 or VB.Net have provided long time ago. >>> For example, the COM interop thing is nice, but then for the past 8 years >>> you know that if you want to script some Office or COM objects you don't use >>> C# or IronPython or (insert dynamic language). >>> But it looks like there are more here. DynamicObject type and >>> IDynamicObject looks intriguing and I wonder it finally allows more natural >>> XML or ActiveRecord object access via property call >>> like myDocument.Customer.Name.FirstName without resorting to some static >>> code generation. I also wonder if this also allows C# to simulate open >>> classes just by putting a hashtable of object and stuff delegate, data, >>> property into them . >>> >>> >>> Dody G. >>> >>> On Tue, Oct 28, 2008 at 1:52 AM, Tim Roberts wrote: >>> >>>> On Tue, 28 Oct 2008 00:36:05 +0200, "Dody Gunawinata" >>>> wrote: >>>> > Yup. It looks like more information needed on all of these dynamic >>>> features. >>>> > In the first glance it looks like C# 4.0 is turning into VB 6 :) >>>> > >>>> >>>> Are you saying that would be a bad thing? Let us recall that VB6 was >>>> arguably the most successful release in Visual Basic history. There are >>>> still people who won't allow themselves to be dragged away from VB6, >>>> more than a decade after its release. >>>> >>>> -- >>>> Tim Roberts, timr at probo.com >>>> Providenza & Boekelheide, Inc. >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> Users at lists.ironpython.com >>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>>> >>> >>> >>> >>> -- >>> nomadlife.org >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >> > > > -- > nomadlife.org > > -- nomadlife.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Oct 30 14:48:57 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Oct 2008 13:48:57 +0000 Subject: [IronPython] help on Vista x64 In-Reply-To: References: <4904C9B9.1000003@voidspace.org.uk> <4904D5AA.4070407@voidspace.org.uk> Message-ID: <4909BB49.6030009@voidspace.org.uk> Curt Clockwatcher wrote: > The code is in IronPython\Runtime\Types\DocBuilder.cs. The specific > code which translates to an XML file is in "XPathDocument > GetXPathDocument(Assembly asm)". > > In theory, we could say "if the file is not found and the pathname > contains 'Framework64', then substitute 'Framework' for 'Framework64' > and try again." > > However, this makes a lot of assumptions about things that are not > actually guaranteed by the framework -- and in particular, are not > likely to be the same under Mono. Well, an *extra* lookup in the wrong place in Mono doesn't seem like it would do any harm - and the current behaviour is basically broken for x64 Vista users. Less broken sounds better to me. ;-) Michael > > On Sun, Oct 26, 2008 at 1:40 PM, Michael Foord > > wrote: > > Curt Hagenlocher wrote: > > The XML documentation files under the > %windir%\Microsoft.NET\Framework directory are not duplicated > under %windir%\Microsoft.NET\Framework64 -- that's why we're > not finding them. As a workaround, you could probably just > copy the files from the one location to the other -- or even > create hard links or symbolic links under Vista using "mklink". > > > Where is the code that looks for these XML files? Could it be made > to look in the correct place? > > I'm not looking for a short term workaround but thinking of > IronPython users on 64 bit systems (plus I'm not sure if it is too > late to document the workaround in my book... :-) > > Michael > > > On Sun, Oct 26, 2008 at 12:49 PM, Michael Foord > > >> wrote: > > Hello guys, > > Using help on methods of .NET types on 32 bit Vista prints > useful > information. e.g. for help(Stack.Push) > > help(Stack.Push) > > Help on method-descriptor Push > | Push(...) > | Push(self, object obj) > | > | Inserts an object at the top of the > | System.Collections.Stack. > | > | obj: The System.Object to push onto the > | System.Collections.Stack. The value can be null. > > > On Vista x64 it prints: > > help(Stack.Push) > > Help on method_descriptor: > > Push(...) > Push(self, object obj) > > Michael Foord > > -- http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > > > > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From fuzzyman at voidspace.org.uk Thu Oct 30 17:02:19 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Oct 2008 16:02:19 +0000 Subject: [IronPython] ScriptScope Oddity Message-ID: <4909DA8B.6050408@voidspace.org.uk> Why does setting '__file__' to None on a ScriptScope through 'SetVariable' fail, whilst setting it directly as an attribute (from inside IronPython) succeeds? Is this intentional? >>> scope >>> scope.SetVariable('__file__', None) Traceback (most recent call last): File "", line 1, in TypeError: Value cannot be null. Parameter name: handle >>> scope.__file__ = None >>> Michael -- http://www.ironpythoninaction.com/ From dinov at microsoft.com Thu Oct 30 17:06:43 2008 From: dinov at microsoft.com (Dino Viehland) Date: Thu, 30 Oct 2008 09:06:43 -0700 Subject: [IronPython] ScriptScope Oddity In-Reply-To: <4909DA8B.6050408@voidspace.org.uk> References: <4909DA8B.6050408@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23554FF717F564@NA-EXMSG-C102.redmond.corp.microsoft.com> We're picking the ObjectHandle overload for some reason. You can use .Overloads to select the correct overload. I'm actually surprised you don't get a different type error saying the call is ambiguous so I'll have to take a deeper look to understand that. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, October 30, 2008 9:02 AM To: Discussion of IronPython Subject: [IronPython] ScriptScope Oddity Why does setting '__file__' to None on a ScriptScope through 'SetVariable' fail, whilst setting it directly as an attribute (from inside IronPython) succeeds? Is this intentional? >>> scope >>> scope.SetVariable('__file__', None) Traceback (most recent call last): File "", line 1, in TypeError: Value cannot be null. Parameter name: handle >>> scope.__file__ = None >>> Michael -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From xkenneth at gmail.com Thu Oct 30 18:34:55 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Thu, 30 Oct 2008 12:34:55 -0500 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com> References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> <9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com> <5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com> Message-ID: Seo, I started a new project on bitbucket.org as I wanted the project to have a different name and a broader scope than simply clipath. Take a look, and let's keep rolling. http://www.bitbucket.org/xkenneth/atheneum/src/tip/atheneum/ Regards, Ken On Oct 29, 2008, at 11:19 AM, Seo Sanghyeon wrote: > 2008/10/30 Kenneth Miller : >> Seo, >> Can you give me access to this code? I signed up on bitbucket as >> xkenneth. > > Done. > > -- > Seo Sanghyeon > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Oct 30 19:20:23 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Oct 2008 18:20:23 +0000 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> <9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com> <5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com> Message-ID: <4909FAE7.4000309@voidspace.org.uk> Kenneth Miller wrote: > Seo, > > I started a new project on bitbucket.org as I wanted the project to > have a different name and a broader scope than simply clipath. Take a > look, and let's keep rolling. > > http://www.bitbucket.org/xkenneth/atheneum/src/tip/atheneum/ Where are the tests? Michael > > Regards, > Ken > > On Oct 29, 2008, at 11:19 AM, Seo Sanghyeon wrote: > >> 2008/10/30 Kenneth Miller > >: >>> Seo, >>> Can you give me access to this code? I signed up on bitbucket as >>> xkenneth. >> >> Done. >> >> -- >> 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 > -- http://www.ironpythoninaction.com/ From fuzzyman at voidspace.org.uk Thu Oct 30 19:38:45 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Oct 2008 18:38:45 +0000 Subject: [IronPython] ScriptScope Oddity In-Reply-To: <350E7D38B6D819428718949920EC23554FF717F564@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <4909DA8B.6050408@voidspace.org.uk> <350E7D38B6D819428718949920EC23554FF717F564@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <4909FF35.90400@voidspace.org.uk> Dino Viehland wrote: > We're picking the ObjectHandle overload for some reason. You can use .Overloads to select the correct overload. I'm actually surprised you don't get a different type error saying the call is ambiguous so I'll have to take a deeper look to understand that. > Actually, this rings a bell. I think I might have asked this question before and received the same answer... Thanks for the quick reply! Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Thursday, October 30, 2008 9:02 AM > To: Discussion of IronPython > Subject: [IronPython] ScriptScope Oddity > > Why does setting '__file__' to None on a ScriptScope through > 'SetVariable' fail, whilst setting it directly as an attribute (from > inside IronPython) succeeds? Is this intentional? > > >>> scope > [Microsoft > .Scripting.Hosting.ScriptScope]> > >>> scope.SetVariable('__file__', None) > Traceback (most recent call last): > File "", line 1, in > TypeError: Value cannot be null. > Parameter name: handle > >>> scope.__file__ = None > >>> > > Michael > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From sanxiyn at gmail.com Thu Oct 30 19:53:29 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Fri, 31 Oct 2008 03:53:29 +0900 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <4909FAE7.4000309@voidspace.org.uk> References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> <9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com> <5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com> <4909FAE7.4000309@voidspace.org.uk> Message-ID: <5b0248170810301153y448e7236yb2069a0c65174ea3@mail.gmail.com> 2008/10/31 Michael Foord : > Kenneth Miller wrote: >> http://www.bitbucket.org/xkenneth/atheneum/src/tip/atheneum/ > Where are the tests? Apparently here: http://www.bitbucket.org/xkenneth/atheneum/src/ A sibling directory, not a child directory. -- Seo Sanghyeon From fuzzyman at voidspace.org.uk Thu Oct 30 21:48:42 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Oct 2008 20:48:42 +0000 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <5b0248170810301153y448e7236yb2069a0c65174ea3@mail.gmail.com> References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> <9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com> <5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com> <4909FAE7.4000309@voidspace.org.uk> <5b0248170810301153y448e7236yb2069a0c65174ea3@mail.gmail.com> Message-ID: <490A1DAA.3010200@voidspace.org.uk> Seo Sanghyeon wrote: > 2008/10/31 Michael Foord : > >> Kenneth Miller wrote: >> >>> http://www.bitbucket.org/xkenneth/atheneum/src/tip/atheneum/ >>> >> Where are the tests? >> > > Apparently here: > http://www.bitbucket.org/xkenneth/atheneum/src/ > > A sibling directory, not a child directory. > > Ah. Thanks :-) Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From xkenneth at gmail.com Thu Oct 30 23:27:15 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Thu, 30 Oct 2008 17:27:15 -0500 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <490A1DAA.3010200@voidspace.org.uk> References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> <9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com> <5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com> <4909FAE7.4000309@voidspace.org.uk> <5b0248170810301153y448e7236yb2069a0c65174ea3@mail.gmail.com> <490A1DAA.3010200@voidspace.org.uk> Message-ID: <97764E78-94CA-429C-BE01-3006D2244573@gmail.com> So, Before I get to into this, does this project hold merit for anyone but myself? Would anyone outside of Seo and I like to see it move forward. I like to spend my time on worthwhile adventures. Like I said before, the main motivation here is to have access to common python standard library operations (even if mapped to .NET) in Silverlight apps without having to include the python standard library itself. Regards, Ken On Oct 30, 2008, at 3:48 PM, Michael Foord wrote: > Seo Sanghyeon wrote: >> 2008/10/31 Michael Foord : >> >>> Kenneth Miller wrote: >>> >>>> http://www.bitbucket.org/xkenneth/atheneum/src/tip/atheneum/ >>>> >>> Where are the tests? >>> >> >> Apparently here: >> http://www.bitbucket.org/xkenneth/atheneum/src/ >> >> A sibling directory, not a child directory. >> >> > Ah. Thanks :-) > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Thu Oct 30 23:30:36 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Oct 2008 22:30:36 +0000 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <97764E78-94CA-429C-BE01-3006D2244573@gmail.com> References: <5b0248170810281147w3554c0e2m2946f56e6272b675@mail.gmail.com> <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> <9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com> <5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com> <4909FAE7.4000309@voidspace.org.uk> <5b0248170810301153y448e7236yb2069a0c65174ea3@mail.gmail.com> <490A1DAA.3010200@voidspace.org.uk> <97764E78-94CA-429C-BE01-3006D2244573@gmail.com> Message-ID: <490A358C.5020205@voidspace.org.uk> Kenneth Miller wrote: > So, > > Before I get to into this, does this project hold merit for anyone > but myself? Would anyone outside of Seo and I like to see it move > forward. I like to spend my time on worthwhile adventures. Like I said > before, the main motivation here is to have access to common python > standard library operations (even if mapped to .NET) in Silverlight > apps without having to include the python standard library itself. It certainly sounds interesting to me. Michael > > Regards, > Ken > > On Oct 30, 2008, at 3:48 PM, Michael Foord wrote: > >> Seo Sanghyeon wrote: >>> 2008/10/31 Michael Foord >> >: >>> >>>> Kenneth Miller wrote: >>>> >>>>> http://www.bitbucket.org/xkenneth/atheneum/src/tip/atheneum/ >>>>> >>>> Where are the tests? >>>> >>> >>> Apparently here: >>> http://www.bitbucket.org/xkenneth/atheneum/src/ >>> >>> A sibling directory, not a child directory. >>> >>> >> Ah. Thanks :-) >> >> Michael >> >> -- >> http://www.ironpythoninaction.com/ >> http://www.voidspace.org.uk/blog >> >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From fuzzyman at voidspace.org.uk Thu Oct 30 23:55:41 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Thu, 30 Oct 2008 22:55:41 +0000 Subject: [IronPython] How can you create set/frozenset from C# ? In-Reply-To: <4817b6fc0810181255o40781323uaf62e362f8110d00@mail.gmail.com> References: <4817b6fc0810181255o40781323uaf62e362f8110d00@mail.gmail.com> Message-ID: <490A3B6D.4070309@voidspace.org.uk> Dan Eloff wrote: > It seems to me that you have to use __init__/__new__ supplying > CodeContext as necessary. Unlike list and tuple which have public > constructors and PythonOps helpers, there doesn't seem to be any > public api for creating sets. Am I right? > > Thanks, > -Dan > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > SetCollection has a public constructor. If you need the CodeContext for __new__ then you can get one like this: LanguageContext language = HostingHelpers.GetLanguageContext(engine); CodeContext co = new CodeContext(new Scope(), language) Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From sanxiyn at gmail.com Fri Oct 31 01:05:01 2008 From: sanxiyn at gmail.com (Seo Sanghyeon) Date: Fri, 31 Oct 2008 09:05:01 +0900 Subject: [IronPython] An issue with using System.Xml as a Python DOM implementation Message-ID: <5b0248170810301705q1b96b2efi469f269c8e17c0da@mail.gmail.com> I am not sure to whom this mail should be addressed. Please help if you know. I am considering the idea of using System.Xml as a Python DOM implementation again. After some experimentation, one issue is this: an idiomatic way to check for the type of DOM node in Python is: if node.nodeType == node.ELEMENT_NODE: nodeType is spelled NodeType with capital N in .NET, but that's fine. I can translate naming convention. The problem is that .NET's XmlNode type does not have attributes for DOM node types, that is, ELEMENT_NODE, ATTRIBUTE_NODE, etc. Instead, these attributes ara available under XmlNodeType enumeration, with wholly different names, like Element, Attribute, etc. My question is, why is this blatant incompatibility? DOM level 1 Core standard http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html seems to clearly say that Node interface should have constants like ELEMENT_NODE, ATTRIBUTE_NODE, etc. defined. -- Seo Sanghyeon From curt at hagenlocher.org Fri Oct 31 02:01:51 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Thu, 30 Oct 2008 18:01:51 -0700 Subject: [IronPython] An issue with using System.Xml as a Python DOM implementation In-Reply-To: <5b0248170810301705q1b96b2efi469f269c8e17c0da@mail.gmail.com> References: <5b0248170810301705q1b96b2efi469f269c8e17c0da@mail.gmail.com> Message-ID: It's not reasonable to view the specification as prescribing syntax; what it specifies are the *semantics* of the DOM, and naturally, different languages and environments will implement these semantics differently. Presumably, NodeType wasn't described as an enumeration in the document because neither IDL nor Java supported enumerations at the time. My question is, why does the answer matter? On Thu, Oct 30, 2008 at 5:05 PM, Seo Sanghyeon wrote: > I am not sure to whom this mail should be addressed. Please help if you > know. > > I am considering the idea of using System.Xml as a Python DOM > implementation again. After some experimentation, one issue is this: > an idiomatic way to check for the type of DOM node in Python is: > > if node.nodeType == node.ELEMENT_NODE: > > nodeType is spelled NodeType with capital N in .NET, but that's fine. > I can translate naming convention. The problem is that .NET's XmlNode > type does not have attributes for DOM node types, that is, > ELEMENT_NODE, ATTRIBUTE_NODE, etc. Instead, these attributes ara > available under XmlNodeType enumeration, with wholly different names, > like Element, Attribute, etc. > > My question is, why is this blatant incompatibility? > > DOM level 1 Core standard > http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html > > seems to clearly say that Node interface should have constants like > ELEMENT_NODE, ATTRIBUTE_NODE, etc. defined. > > -- > Seo Sanghyeon > _______________________________________________ > 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 michael.foord at resolversystems.com Fri Oct 31 12:52:09 2008 From: michael.foord at resolversystems.com (Michael Foord) Date: Fri, 31 Oct 2008 11:52:09 +0000 Subject: [IronPython] Confusing Error Message Message-ID: <490AF169.6070007@resolversystems.com> This had me foxed for a while: CPython >>> 'a' in object() Traceback (most recent call last): File "", line 1, in ? TypeError: iterable argument required >>> IronPython (changeset 42603) >>> 'a' in object() Traceback (most recent call last): File "", line 1, in TypeError: argument of type 'str' is not iterable >>> -- Michael Foord Senior Software Engineer, Resolver Systems Ltd. michael.foord at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From michael.foord at resolversystems.com Fri Oct 31 13:23:35 2008 From: michael.foord at resolversystems.com (Michael Foord) Date: Fri, 31 Oct 2008 12:23:35 +0000 Subject: [IronPython] 2.1 Branch in Codeplex Sources Message-ID: <490AF8C7.7080103@resolversystems.com> Hello guys, I saw a while ago a note about some of the Codeplex source pushes containing code for the 2.1 branch rather than 2.0. Is it possible to tell which is which when we download a changeset? I've just downloaded 42708 (we're trying to keep the Resolver One port using the latest sources to minimise unexpected changes) and it contains 'IronPython_Main' and 'IronPython_2_0'. The assembly info for main shows: AssemblyVersion("2.0.0.5000")] Is this still the 2.0 branch or should I be using 'IronPython_2_0'? How about some checkin messages to go along with the source code drops? "Latest sources migrated to CodePlex TFS" is not terribly informative... Michael -- Michael Foord Senior Software Engineer, Resolver Systems Ltd. michael.foord at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From michael.foord at resolversystems.com Fri Oct 31 14:53:45 2008 From: michael.foord at resolversystems.com (Michael Foord) Date: Fri, 31 Oct 2008 13:53:45 +0000 Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython Message-ID: <490B0DE9.2020707@resolversystems.com> Hello guys, In Resolver One we use the IronPython hosting API from inside IronPython code. I've noticed an oddity that is not how I would expect the hosting API to behave if I was using it from C#. My understanding is that the correct way to publish a module (make it available for a ScriptEngine to import) is to set it in 'engine.Runtime.Globals'. If I do this from within IronPython code with a module I have already imported and then execute an import statement in the engine, the module is re-imported (code executed) rather than using the one I have published to the runtime globals. If I have a 'foobar' module that prints when importing, the following code prints twice instead of the once I would expect: import sys import clr clr.AddReference('IronPython') clr.AddReference('Microsoft.Scripting') from IronPython.Hosting import Python from Microsoft.Scripting import SourceCodeKind import foobar engine = Python.CreateEngine() engine.Runtime.Globals.SetVariable('foobar', sys.modules['foobar']) source = engine.CreateScriptSourceFromString('import foobar\r\n', SourceCodeKind.Statements) scope = engine.CreateScope() source.Compile().Execute(scope) *However*, if I change the code to not use Runtime.Globals, but instead do the following, then the module is only imported once and I get one print as expected: hostedSys = Python.GetSysModule(engine) hostedSys.modules['foobar'] = sys.modules['foobar'] Is there something I have overlooked here? As a minor supplementary question, how do I get a reference to the default ScriptScope on an engine? Is there any performance advantage in using the default one, can I replace it, and does replacing it remove any performance benefits we might have got? (OK, so strictly speaking that wasn't just one question...) All the best, Michael Foord -- Michael Foord Senior Software Engineer, Resolver Systems Ltd. michael.foord at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK From curt at hagenlocher.org Fri Oct 31 15:03:52 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 31 Oct 2008 07:03:52 -0700 Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython In-Reply-To: <490B0DE9.2020707@resolversystems.com> References: <490B0DE9.2020707@resolversystems.com> Message-ID: I don't know the answer to your question (and don't have the source code with me on the bus) but by calling Python.CreateEngine(), you're now creating a second copy of the runtime. Notionally, the runtimes are independent of each other and I would expect there to be a second import when the same module is used in both. On Fri, Oct 31, 2008 at 6:53 AM, Michael Foord < michael.foord at resolversystems.com> wrote: > Hello guys, > > In Resolver One we use the IronPython hosting API from inside IronPython > code. I've noticed an oddity that is not how I would expect the hosting API > to behave if I was using it from C#. > > My understanding is that the correct way to publish a module (make it > available for a ScriptEngine to import) is to set it in > 'engine.Runtime.Globals'. > > If I do this from within IronPython code with a module I have already > imported and then execute an import statement in the engine, the module is > re-imported (code executed) rather than using the one I have published to > the runtime globals. > > If I have a 'foobar' module that prints when importing, the following code > prints twice instead of the once I would expect: > > import sys > import clr > clr.AddReference('IronPython') > clr.AddReference('Microsoft.Scripting') > > from IronPython.Hosting import Python > from Microsoft.Scripting import SourceCodeKind > > import foobar > > engine = Python.CreateEngine() > engine.Runtime.Globals.SetVariable('foobar', sys.modules['foobar']) > > source = engine.CreateScriptSourceFromString('import foobar\r\n', > SourceCodeKind.Statements) > scope = engine.CreateScope() > source.Compile().Execute(scope) > > > *However*, if I change the code to not use Runtime.Globals, but instead do > the following, then the module is only imported once and I get one print as > expected: > > hostedSys = Python.GetSysModule(engine) > hostedSys.modules['foobar'] = sys.modules['foobar'] > > Is there something I have overlooked here? > > As a minor supplementary question, how do I get a reference to the default > ScriptScope on an engine? Is there any performance advantage in using the > default one, can I replace it, and does replacing it remove any performance > benefits we might have got? (OK, so strictly speaking that wasn't just one > question...) > > All the best, > > Michael Foord > > -- > Michael Foord > Senior Software Engineer, Resolver Systems Ltd. > michael.foord at resolversystems.com > +44 (0) 20 7253 6372 > > Try out Resolver One! > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 Registered in England and Wales as company number > 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From curt at hagenlocher.org Fri Oct 31 15:06:30 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 31 Oct 2008 07:06:30 -0700 Subject: [IronPython] 2.1 Branch in Codeplex Sources In-Reply-To: <490AF8C7.7080103@resolversystems.com> References: <490AF8C7.7080103@resolversystems.com> Message-ID: Sorry, we should have been more explicit about this. The IronPython_2_0 branch is the 2.0 branch now. Other than some tests that Dave added recently, I don't think that there have been any source changes made since the RC was released. We often don't update the assembly info until we're ready to push an "official" release. Mostly, even. But what's in the main branch is effectively IronPython 2.1, no matter what the assembly version says. On Fri, Oct 31, 2008 at 5:23 AM, Michael Foord < michael.foord at resolversystems.com> wrote: > Hello guys, > > I saw a while ago a note about some of the Codeplex source pushes > containing code for the 2.1 branch rather than 2.0. > > Is it possible to tell which is which when we download a changeset? > > I've just downloaded 42708 (we're trying to keep the Resolver One port > using the latest sources to minimise unexpected changes) and it contains > 'IronPython_Main' and 'IronPython_2_0'. > > The assembly info for main shows: AssemblyVersion("2.0.0.5000")] > > Is this still the 2.0 branch or should I be using 'IronPython_2_0'? > > How about some checkin messages to go along with the source code drops? > "Latest sources migrated to CodePlex TFS" is not terribly informative... > > Michael > > -- > Michael Foord > Senior Software Engineer, Resolver Systems Ltd. > michael.foord at resolversystems.com > +44 (0) 20 7253 6372 > > Try out Resolver One! > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 Registered in England and Wales as company number > 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Fri Oct 31 15:07:02 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 31 Oct 2008 14:07:02 +0000 Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython In-Reply-To: References: <490B0DE9.2020707@resolversystems.com> Message-ID: <490B1106.5040301@voidspace.org.uk> Curt Hagenlocher wrote: > I don't know the answer to your question (and don't have the source > code with me on the bus) but by calling Python.CreateEngine(), you're > now creating a second copy of the runtime. Notionally, the runtimes > are independent of each other and I would expect there to be a second > import when the same module is used in both. Yes - which is why the code explicitly adds the module to the runtime associated with the engine we have just created. At least the theory was that this would publish the already imported module to the new engine, and make it available for import without having to re-execute the module. Michael > > On Fri, Oct 31, 2008 at 6:53 AM, Michael Foord > > wrote: > > Hello guys, > > In Resolver One we use the IronPython hosting API from inside > IronPython code. I've noticed an oddity that is not how I would > expect the hosting API to behave if I was using it from C#. > > My understanding is that the correct way to publish a module (make > it available for a ScriptEngine to import) is to set it in > 'engine.Runtime.Globals'. > > If I do this from within IronPython code with a module I have > already imported and then execute an import statement in the > engine, the module is re-imported (code executed) rather than > using the one I have published to the runtime globals. > > If I have a 'foobar' module that prints when importing, the > following code prints twice instead of the once I would expect: > > import sys > import clr > clr.AddReference('IronPython') > clr.AddReference('Microsoft.Scripting') > > from IronPython.Hosting import Python > from Microsoft.Scripting import SourceCodeKind > > import foobar > > engine = Python.CreateEngine() > engine.Runtime.Globals.SetVariable('foobar', sys.modules['foobar']) > > source = engine.CreateScriptSourceFromString('import foobar\r\n', > SourceCodeKind.Statements) > scope = engine.CreateScope() > source.Compile().Execute(scope) > > > *However*, if I change the code to not use Runtime.Globals, but > instead do the following, then the module is only imported once > and I get one print as expected: > > hostedSys = Python.GetSysModule(engine) > hostedSys.modules['foobar'] = sys.modules['foobar'] > > Is there something I have overlooked here? > > As a minor supplementary question, how do I get a reference to the > default ScriptScope on an engine? Is there any performance > advantage in using the default one, can I replace it, and does > replacing it remove any performance benefits we might have got? > (OK, so strictly speaking that wasn't just one question...) > > All the best, > > Michael Foord > > -- > Michael Foord > Senior Software Engineer, Resolver Systems Ltd. > michael.foord at resolversystems.com > > +44 (0) 20 7253 6372 > > Try out Resolver One! > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 Registered in England and Wales as company > number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From fuzzyman at voidspace.org.uk Fri Oct 31 15:08:11 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 31 Oct 2008 14:08:11 +0000 Subject: [IronPython] 2.1 Branch in Codeplex Sources In-Reply-To: References: <490AF8C7.7080103@resolversystems.com> Message-ID: <490B114B.6000502@voidspace.org.uk> Curt Hagenlocher wrote: > Sorry, we should have been more explicit about this. The > IronPython_2_0 branch is the 2.0 branch now. Other than some tests > that Dave added recently, I don't think that there have been any > source changes made since the RC was released. > > We often don't update the assembly info until we're ready to push an > "official" release. Mostly, even. But what's in the main branch is > effectively IronPython 2.1, no matter what the assembly version says. > Thanks Curt. Michael > On Fri, Oct 31, 2008 at 5:23 AM, Michael Foord > > wrote: > > Hello guys, > > I saw a while ago a note about some of the Codeplex source pushes > containing code for the 2.1 branch rather than 2.0. > > Is it possible to tell which is which when we download a changeset? > > I've just downloaded 42708 (we're trying to keep the Resolver One > port using the latest sources to minimise unexpected changes) and > it contains 'IronPython_Main' and 'IronPython_2_0'. > > The assembly info for main shows: AssemblyVersion("2.0.0.5000")] > > Is this still the 2.0 branch or should I be using 'IronPython_2_0'? > > How about some checkin messages to go along with the source code > drops? "Latest sources migrated to CodePlex TFS" is not terribly > informative... > > Michael > > -- > Michael Foord > Senior Software Engineer, Resolver Systems Ltd. > michael.foord at resolversystems.com > > +44 (0) 20 7253 6372 > > Try out Resolver One! > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 Registered in England and Wales as company > number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From curt at hagenlocher.org Fri Oct 31 15:12:31 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 31 Oct 2008 07:12:31 -0700 Subject: [IronPython] 2.1 Branch in Codeplex Sources In-Reply-To: <490AF8C7.7080103@resolversystems.com> References: <490AF8C7.7080103@resolversystems.com> Message-ID: Oh, regarding the comments -- we have two separate issues. 1. The "push" job runs on a scheduled basis, so it's not just copying a single checkin. It could theoretically aggregate multiple comments, but there are some mechanical problems involved in that. 2. More importantly, they sometimes contain text like "updated the CSharp binder" which refer to things that the company hasn't made public yet. On Fri, Oct 31, 2008 at 5:23 AM, Michael Foord < michael.foord at resolversystems.com> wrote: > Hello guys, > > I saw a while ago a note about some of the Codeplex source pushes > containing code for the 2.1 branch rather than 2.0. > > Is it possible to tell which is which when we download a changeset? > > I've just downloaded 42708 (we're trying to keep the Resolver One port > using the latest sources to minimise unexpected changes) and it contains > 'IronPython_Main' and 'IronPython_2_0'. > > The assembly info for main shows: AssemblyVersion("2.0.0.5000")] > > Is this still the 2.0 branch or should I be using 'IronPython_2_0'? > > How about some checkin messages to go along with the source code drops? > "Latest sources migrated to CodePlex TFS" is not terribly informative... > > Michael > > -- > Michael Foord > Senior Software Engineer, Resolver Systems Ltd. > michael.foord at resolversystems.com > +44 (0) 20 7253 6372 > > Try out Resolver One! > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 Registered in England and Wales as company number > 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Fri Oct 31 15:21:18 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 31 Oct 2008 14:21:18 +0000 Subject: [IronPython] 2.1 Branch in Codeplex Sources In-Reply-To: References: <490AF8C7.7080103@resolversystems.com> Message-ID: <490B145E.8090304@voidspace.org.uk> Curt Hagenlocher wrote: > Oh, regarding the comments -- we have two separate issues. > 1. The "push" job runs on a scheduled basis, so it's not just copying > a single checkin. It could theoretically aggregate multiple comments, > but there are some mechanical problems involved in that. Not hard problems though (mechanical!?) surely? > 2. More importantly, they sometimes contain text like "updated the > CSharp binder" which refer to things that the company hasn't made > public yet. > It only happens a couple of times a week - perhaps a keyword or marker on lines of checkin messages to filter them out? Useful checkin messages would be *great*. Michael > On Fri, Oct 31, 2008 at 5:23 AM, Michael Foord > > wrote: > > Hello guys, > > I saw a while ago a note about some of the Codeplex source pushes > containing code for the 2.1 branch rather than 2.0. > > Is it possible to tell which is which when we download a changeset? > > I've just downloaded 42708 (we're trying to keep the Resolver One > port using the latest sources to minimise unexpected changes) and > it contains 'IronPython_Main' and 'IronPython_2_0'. > > The assembly info for main shows: AssemblyVersion("2.0.0.5000")] > > Is this still the 2.0 branch or should I be using 'IronPython_2_0'? > > How about some checkin messages to go along with the source code > drops? "Latest sources migrated to CodePlex TFS" is not terribly > informative... > > Michael > > -- > Michael Foord > Senior Software Engineer, Resolver Systems Ltd. > michael.foord at resolversystems.com > > +44 (0) 20 7253 6372 > > Try out Resolver One! > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 Registered in England and Wales as company > number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From fuzzyman at voidspace.org.uk Fri Oct 31 15:35:08 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 31 Oct 2008 14:35:08 +0000 Subject: [IronPython] Oddity with Setting Output Stream Message-ID: <490B179C.5040608@voidspace.org.uk> Hello guys, Another oddity with the IronPython 2 hosting API. This one may be the correct behaviour, but it is different from IronPython 1. When we set a UTF8 output stream on a runtime we see a UTF8 BOM being written with the first output. I'm sure this didn't happen with IronPython 1 because I now have failing tests! The following code that traps standard out using a custom stream prints: out: u'\ufeff' out: 'foobar' out: '\r\n' out: 'foobar' out: '\r\n' import sys import clr clr.AddReference('IronPython') clr.AddReference('Microsoft.Scripting') from IronPython.Hosting import Python from Microsoft.Scripting import SourceCodeKind from System.Text import Encoding from System.IO import MemoryStream class CustomStream(MemoryStream): def __new__(cls, prefix): return MemoryStream.__new__(cls) def __init__(self, prefix): self._prefix = prefix def Write(self, buffer, offset, count): print self._prefix, print repr(Encoding.UTF8.GetString(buffer, offset, count)) engine = Python.CreateEngine() engine.Runtime.IO.SetOutput(CustomStream('out:'), Encoding.UTF8) source = engine.CreateScriptSourceFromString('print "foobar"\r\n', SourceCodeKind.Statements) scope = engine.CreateScope() code = source.Compile() code.Execute(scope) code.Execute(scope) All the best, Michael Foord -- http://www.ironpythoninaction.com/ From dblank at brynmawr.edu Fri Oct 31 16:45:52 2008 From: dblank at brynmawr.edu (Douglas Blank) Date: Fri, 31 Oct 2008 11:45:52 -0400 (EDT) Subject: [IronPython] Latest Hosting API Message-ID: <2043236941.420391225467952362.JavaMail.root@ganesh.brynmawr.edu> What sources do you recommended for the latest IronPython RC1 hosting API? As far as I have found most docs still use older API's and I don't think Foord and Muirhead's latest available MEAP e-version is out yet. Thanks! -Doug From curt at hagenlocher.org Fri Oct 31 17:19:14 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 31 Oct 2008 09:19:14 -0700 Subject: [IronPython] Latest Hosting API In-Reply-To: <2043236941.420391225467952362.JavaMail.root@ganesh.brynmawr.edu> References: <2043236941.420391225467952362.JavaMail.root@ganesh.brynmawr.edu> Message-ID: The API documentation itself can be found at http://compilerlab.members.winisp.net/dlr-spec-hosting.pdf (PDF) or http://compilerlab.members.winisp.net/dlr-spec-hosting.doc (Word). An update was just pushed yesterday. On Fri, Oct 31, 2008 at 8:45 AM, Douglas Blank wrote: > What sources do you recommended for the latest IronPython RC1 hosting API? > As far as I have found most docs still use older API's and I don't think > Foord and Muirhead's latest available MEAP e-version is out yet. Thanks! > > -Doug > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dinov at microsoft.com Fri Oct 31 17:25:49 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 31 Oct 2008 09:25:49 -0700 Subject: [IronPython] Confusing Error Message In-Reply-To: <490AF169.6070007@resolversystems.com> References: <490AF169.6070007@resolversystems.com> Message-ID: <350E7D38B6D819428718949920EC23554FF7266A8F@NA-EXMSG-C102.redmond.corp.microsoft.com> Thanks Michael, I've opened a bug to fix this: http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19278 -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, October 31, 2008 4:52 AM To: Discussion of IronPython Subject: [IronPython] Confusing Error Message This had me foxed for a while: CPython >>> 'a' in object() Traceback (most recent call last): File "", line 1, in ? TypeError: iterable argument required >>> IronPython (changeset 42603) >>> 'a' in object() Traceback (most recent call last): File "", line 1, in TypeError: argument of type 'str' is not iterable >>> -- Michael Foord Senior Software Engineer, Resolver Systems Ltd. michael.foord at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Fri Oct 31 17:28:24 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 31 Oct 2008 16:28:24 +0000 Subject: [IronPython] Latest Hosting API In-Reply-To: <2043236941.420391225467952362.JavaMail.root@ganesh.brynmawr.edu> References: <2043236941.420391225467952362.JavaMail.root@ganesh.brynmawr.edu> Message-ID: <490B3228.2020407@voidspace.org.uk> Douglas Blank wrote: > What sources do you recommended for the latest IronPython RC1 hosting API? As far as I have found most docs still use older API's and I don't think Foord and Muirhead's latest available MEAP e-version is out yet. Thanks! > > The latest MEAP has all fifteen chapters, and whilst ch. 15 in the last released MEAP is slightly out of date it should be mainly using the new APIs. Michael Foord > -Doug > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From dinov at microsoft.com Fri Oct 31 17:30:12 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 31 Oct 2008 09:30:12 -0700 Subject: [IronPython] 2.1 Branch in Codeplex Sources In-Reply-To: <490AF8C7.7080103@resolversystems.com> References: <490AF8C7.7080103@resolversystems.com> Message-ID: <350E7D38B6D819428718949920EC23554FF7266A97@NA-EXMSG-C102.redmond.corp.microsoft.com> Just one other comment on top of what Curt said. You might more properly think of Main as IronPython 3k. Main includes a ton of renames and other breaking made in Microsoft.Scripting.Core/System.Core that will end up in .NET 4.0. We're still working on what we want to do for 2.1 (and input is always welcome of course) but our current thinking is that it will be API compatible w/ 2.0. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, October 31, 2008 5:24 AM To: Discussion of IronPython Subject: [IronPython] 2.1 Branch in Codeplex Sources Hello guys, I saw a while ago a note about some of the Codeplex source pushes containing code for the 2.1 branch rather than 2.0. Is it possible to tell which is which when we download a changeset? I've just downloaded 42708 (we're trying to keep the Resolver One port using the latest sources to minimise unexpected changes) and it contains 'IronPython_Main' and 'IronPython_2_0'. The assembly info for main shows: AssemblyVersion("2.0.0.5000")] Is this still the 2.0 branch or should I be using 'IronPython_2_0'? How about some checkin messages to go along with the source code drops? "Latest sources migrated to CodePlex TFS" is not terribly informative... Michael -- Michael Foord Senior Software Engineer, Resolver Systems Ltd. michael.foord at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dinov at microsoft.com Fri Oct 31 17:36:08 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 31 Oct 2008 09:36:08 -0700 Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython In-Reply-To: <490B0DE9.2020707@resolversystems.com> References: <490B0DE9.2020707@resolversystems.com> Message-ID: <350E7D38B6D819428718949920EC23554FF7266AA5@NA-EXMSG-C102.redmond.corp.microsoft.com> We try to import from the file system before we attempt to import from the DLR (which includes both globals & .NET namespaces). So in this case we'll pick up foobar from disk because presumably these 2 engines both share the entry in sys.path where foobar lives. I think long term this logic is going to move into an importer hook because by CPython 3.1 the import logic may be written entirely in Python. In that case you'd have the ability to re-order the import hooks so you could control the precedence. But for now I think it's by design - we don't want to block potentially valid imports that would work in CPython (e.g. import System :) ). -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, October 31, 2008 6:54 AM To: Discussion of IronPython Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython Hello guys, In Resolver One we use the IronPython hosting API from inside IronPython code. I've noticed an oddity that is not how I would expect the hosting API to behave if I was using it from C#. My understanding is that the correct way to publish a module (make it available for a ScriptEngine to import) is to set it in 'engine.Runtime.Globals'. If I do this from within IronPython code with a module I have already imported and then execute an import statement in the engine, the module is re-imported (code executed) rather than using the one I have published to the runtime globals. If I have a 'foobar' module that prints when importing, the following code prints twice instead of the once I would expect: import sys import clr clr.AddReference('IronPython') clr.AddReference('Microsoft.Scripting') from IronPython.Hosting import Python from Microsoft.Scripting import SourceCodeKind import foobar engine = Python.CreateEngine() engine.Runtime.Globals.SetVariable('foobar', sys.modules['foobar']) source = engine.CreateScriptSourceFromString('import foobar\r\n', SourceCodeKind.Statements) scope = engine.CreateScope() source.Compile().Execute(scope) *However*, if I change the code to not use Runtime.Globals, but instead do the following, then the module is only imported once and I get one print as expected: hostedSys = Python.GetSysModule(engine) hostedSys.modules['foobar'] = sys.modules['foobar'] Is there something I have overlooked here? As a minor supplementary question, how do I get a reference to the default ScriptScope on an engine? Is there any performance advantage in using the default one, can I replace it, and does replacing it remove any performance benefits we might have got? (OK, so strictly speaking that wasn't just one question...) All the best, Michael Foord -- Michael Foord Senior Software Engineer, Resolver Systems Ltd. michael.foord at resolversystems.com +44 (0) 20 7253 6372 Try out Resolver One! 17a Clerkenwell Road, London EC1M 5RD, UK VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. Registered address: 843 Finchley Road, London NW11 8NA, UK _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Fri Oct 31 17:39:40 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 31 Oct 2008 16:39:40 +0000 Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython In-Reply-To: <350E7D38B6D819428718949920EC23554FF7266AA5@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <490B0DE9.2020707@resolversystems.com> <350E7D38B6D819428718949920EC23554FF7266AA5@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <490B34CC.1020607@voidspace.org.uk> Dino Viehland wrote: > We try to import from the file system before we attempt to import from the DLR (which includes both globals & .NET namespaces). So in this case we'll pick up foobar from disk because presumably these 2 engines both share the entry in sys.path where foobar lives. > > I think long term this logic is going to move into an importer hook because by CPython 3.1 the import logic may be written entirely in Python. In that case you'd have the ability to re-order the import hooks so you could control the precedence. But for now I think it's by design - we don't want to block potentially valid imports that would work in CPython (e.g. import System :) ). > So if we want to pre-populate an engine with modules we *ought* to be hooking directly into 'sys.modules' of the hosted engines rather than using runtime.Globals ? Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, October 31, 2008 6:54 AM > To: Discussion of IronPython > Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython > > Hello guys, > > In Resolver One we use the IronPython hosting API from inside IronPython > code. I've noticed an oddity that is not how I would expect the hosting > API to behave if I was using it from C#. > > My understanding is that the correct way to publish a module (make it > available for a ScriptEngine to import) is to set it in > 'engine.Runtime.Globals'. > > If I do this from within IronPython code with a module I have already > imported and then execute an import statement in the engine, the module > is re-imported (code executed) rather than using the one I have > published to the runtime globals. > > If I have a 'foobar' module that prints when importing, the following > code prints twice instead of the once I would expect: > > import sys > import clr > clr.AddReference('IronPython') > clr.AddReference('Microsoft.Scripting') > > from IronPython.Hosting import Python > from Microsoft.Scripting import SourceCodeKind > > import foobar > > engine = Python.CreateEngine() > engine.Runtime.Globals.SetVariable('foobar', sys.modules['foobar']) > > source = engine.CreateScriptSourceFromString('import foobar\r\n', > SourceCodeKind.Statements) > scope = engine.CreateScope() > source.Compile().Execute(scope) > > > *However*, if I change the code to not use Runtime.Globals, but instead > do the following, then the module is only imported once and I get one > print as expected: > > hostedSys = Python.GetSysModule(engine) > hostedSys.modules['foobar'] = sys.modules['foobar'] > > Is there something I have overlooked here? > > As a minor supplementary question, how do I get a reference to the > default ScriptScope on an engine? Is there any performance advantage in > using the default one, can I replace it, and does replacing it remove > any performance benefits we might have got? (OK, so strictly speaking > that wasn't just one question...) > > All the best, > > Michael Foord > > -- > Michael Foord > Senior Software Engineer, Resolver Systems Ltd. > michael.foord at resolversystems.com > +44 (0) 20 7253 6372 > > Try out Resolver One! > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From dinov at microsoft.com Fri Oct 31 17:43:54 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 31 Oct 2008 09:43:54 -0700 Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython In-Reply-To: <490B34CC.1020607@voidspace.org.uk> References: <490B0DE9.2020707@resolversystems.com> <350E7D38B6D819428718949920EC23554FF7266AA5@NA-EXMSG-C102.redmond.corp.microsoft.com> <490B34CC.1020607@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23554FF7266AB3@NA-EXMSG-C102.redmond.corp.microsoft.com> If you also have those modules living on disk in sys.path - yes. But honestly it is a little scary that you're using modules across ScriptRuntime's and I can't say that I'd advise that as a best practice. Of course I don't know that anything will go wrong either but it might get really confusing... -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, October 31, 2008 9:40 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython Dino Viehland wrote: > We try to import from the file system before we attempt to import from the DLR (which includes both globals & .NET namespaces). So in this case we'll pick up foobar from disk because presumably these 2 engines both share the entry in sys.path where foobar lives. > > I think long term this logic is going to move into an importer hook because by CPython 3.1 the import logic may be written entirely in Python. In that case you'd have the ability to re-order the import hooks so you could control the precedence. But for now I think it's by design - we don't want to block potentially valid imports that would work in CPython (e.g. import System :) ). > So if we want to pre-populate an engine with modules we *ought* to be hooking directly into 'sys.modules' of the hosted engines rather than using runtime.Globals ? Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, October 31, 2008 6:54 AM > To: Discussion of IronPython > Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython > > Hello guys, > > In Resolver One we use the IronPython hosting API from inside IronPython > code. I've noticed an oddity that is not how I would expect the hosting > API to behave if I was using it from C#. > > My understanding is that the correct way to publish a module (make it > available for a ScriptEngine to import) is to set it in > 'engine.Runtime.Globals'. > > If I do this from within IronPython code with a module I have already > imported and then execute an import statement in the engine, the module > is re-imported (code executed) rather than using the one I have > published to the runtime globals. > > If I have a 'foobar' module that prints when importing, the following > code prints twice instead of the once I would expect: > > import sys > import clr > clr.AddReference('IronPython') > clr.AddReference('Microsoft.Scripting') > > from IronPython.Hosting import Python > from Microsoft.Scripting import SourceCodeKind > > import foobar > > engine = Python.CreateEngine() > engine.Runtime.Globals.SetVariable('foobar', sys.modules['foobar']) > > source = engine.CreateScriptSourceFromString('import foobar\r\n', > SourceCodeKind.Statements) > scope = engine.CreateScope() > source.Compile().Execute(scope) > > > *However*, if I change the code to not use Runtime.Globals, but instead > do the following, then the module is only imported once and I get one > print as expected: > > hostedSys = Python.GetSysModule(engine) > hostedSys.modules['foobar'] = sys.modules['foobar'] > > Is there something I have overlooked here? > > As a minor supplementary question, how do I get a reference to the > default ScriptScope on an engine? Is there any performance advantage in > using the default one, can I replace it, and does replacing it remove > any performance benefits we might have got? (OK, so strictly speaking > that wasn't just one question...) > > All the best, > > Michael Foord > > -- > Michael Foord > Senior Software Engineer, Resolver Systems Ltd. > michael.foord at resolversystems.com > +44 (0) 20 7253 6372 > > Try out Resolver One! > > 17a Clerkenwell Road, London EC1M 5RD, UK > VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. > Registered address: 843 Finchley Road, London NW11 8NA, UK > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From dblank at brynmawr.edu Fri Oct 31 17:50:57 2008 From: dblank at brynmawr.edu (Douglas Blank) Date: Fri, 31 Oct 2008 12:50:57 -0400 (EDT) Subject: [IronPython] Latest Hosting API - question on evaluating expr/statements In-Reply-To: Message-ID: <2032744044.443921225471857891.JavaMail.root@ganesh.brynmawr.edu> ----- Curt Hagenlocher wrote: > The API documentation itself can be found at > http://compilerlab.members.winisp.net/dlr-spec-hosting.pdf (PDF) or > http://compilerlab.members.winisp.net/dlr-spec-hosting.doc (Word). An > update was just pushed yesterday. Excellent! Thanks much for this. I've taken a look at the updated text, and have a question about evaluating arbitrary user text. I'm allowing the user to evaluate an arbitrary expression OR a sequence of statements. If I use: source = engine.CreateScriptSourceFromString(code, SourceCodeKind.Statements); object result = source.Execute(scope); then it works for statements (with a null result). If I use: source = engine.CreateScriptSourceFromString(code, SourceCodeKind.InteractiveCode); object result = source.Execute(scope); then that works fine with REPL expressions. As there isn't a Kind for either, would there be issues if I do: try { source = engine.CreateScriptSourceFromString(code, SourceCodeKind.Statements); } catch (Exception e1) { try { source = engine.CreateScriptSourceFromString(code, SourceCodeKind.InteractiveCode); } catch (Exception e2) { // report error } } or is there a better way? Thanks! -Doug > On Fri, Oct 31, 2008 at 8:45 AM, Douglas Blank wrote: > > > What sources do you recommended for the latest IronPython RC1 hosting API? > > As far as I have found most docs still use older API's and I don't think > > Foord and Muirhead's latest available MEAP e-version is out yet. Thanks! > > > > -Doug > > _______________________________________________ > > Users mailing list > > Users at lists.ironpython.com > > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > From fuzzyman at voidspace.org.uk Fri Oct 31 17:53:26 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 31 Oct 2008 16:53:26 +0000 Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython In-Reply-To: <350E7D38B6D819428718949920EC23554FF7266AB3@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <490B0DE9.2020707@resolversystems.com> <350E7D38B6D819428718949920EC23554FF7266AA5@NA-EXMSG-C102.redmond.corp.microsoft.com> <490B34CC.1020607@voidspace.org.uk> <350E7D38B6D819428718949920EC23554FF7266AB3@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <490B3806.3090100@voidspace.org.uk> Dino Viehland wrote: > If you also have those modules living on disk in sys.path - yes. But honestly it is a little scary that you're using modules across ScriptRuntime's and I can't say that I'd advise that as a best practice. Of course I don't know that anything will go wrong either but it might get really confusing... > The basic scenario is that our spreadsheets use a host of our spreadsheet model libraries. If every new document has to import these from scratch then it drastically increases the time (and memory use) associated with creating a new document and doing the first calculation. Of course if importing large amounts of Python code was quicker and used less memory it wouldn't be such an issue. ;-) If a single runtime could have multiple Python engines associated then we could do that, but as far as I can tell creating a new engine from a runtime with an existing engine will always return the existing engine? Though as they are all using the same libraries it seems sensible for them to be shared rather than each document holding an identical copy. If at some point we move to isolate documents using AppDomains then this will obviously change - but the time cost of a new document having to import everything from scratch is a factor in being able to do that. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, October 31, 2008 9:40 AM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython > > Dino Viehland wrote: > >> We try to import from the file system before we attempt to import from the DLR (which includes both globals & .NET namespaces). So in this case we'll pick up foobar from disk because presumably these 2 engines both share the entry in sys.path where foobar lives. >> >> I think long term this logic is going to move into an importer hook because by CPython 3.1 the import logic may be written entirely in Python. In that case you'd have the ability to re-order the import hooks so you could control the precedence. But for now I think it's by design - we don't want to block potentially valid imports that would work in CPython (e.g. import System :) ). >> >> > > So if we want to pre-populate an engine with modules we *ought* to be > hooking directly into 'sys.modules' of the hosted engines rather than > using runtime.Globals ? > > Michael > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Friday, October 31, 2008 6:54 AM >> To: Discussion of IronPython >> Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython >> >> Hello guys, >> >> In Resolver One we use the IronPython hosting API from inside IronPython >> code. I've noticed an oddity that is not how I would expect the hosting >> API to behave if I was using it from C#. >> >> My understanding is that the correct way to publish a module (make it >> available for a ScriptEngine to import) is to set it in >> 'engine.Runtime.Globals'. >> >> If I do this from within IronPython code with a module I have already >> imported and then execute an import statement in the engine, the module >> is re-imported (code executed) rather than using the one I have >> published to the runtime globals. >> >> If I have a 'foobar' module that prints when importing, the following >> code prints twice instead of the once I would expect: >> >> import sys >> import clr >> clr.AddReference('IronPython') >> clr.AddReference('Microsoft.Scripting') >> >> from IronPython.Hosting import Python >> from Microsoft.Scripting import SourceCodeKind >> >> import foobar >> >> engine = Python.CreateEngine() >> engine.Runtime.Globals.SetVariable('foobar', sys.modules['foobar']) >> >> source = engine.CreateScriptSourceFromString('import foobar\r\n', >> SourceCodeKind.Statements) >> scope = engine.CreateScope() >> source.Compile().Execute(scope) >> >> >> *However*, if I change the code to not use Runtime.Globals, but instead >> do the following, then the module is only imported once and I get one >> print as expected: >> >> hostedSys = Python.GetSysModule(engine) >> hostedSys.modules['foobar'] = sys.modules['foobar'] >> >> Is there something I have overlooked here? >> >> As a minor supplementary question, how do I get a reference to the >> default ScriptScope on an engine? Is there any performance advantage in >> using the default one, can I replace it, and does replacing it remove >> any performance benefits we might have got? (OK, so strictly speaking >> that wasn't just one question...) >> >> All the best, >> >> Michael Foord >> >> -- >> Michael Foord >> Senior Software Engineer, Resolver Systems Ltd. >> michael.foord at resolversystems.com >> +44 (0) 20 7253 6372 >> >> Try out Resolver One! >> >> 17a Clerkenwell Road, London EC1M 5RD, UK >> VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. >> Registered address: 843 Finchley Road, London NW11 8NA, UK >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From dinov at microsoft.com Fri Oct 31 17:57:39 2008 From: dinov at microsoft.com (Dino Viehland) Date: Fri, 31 Oct 2008 09:57:39 -0700 Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython In-Reply-To: <490B3806.3090100@voidspace.org.uk> References: <490B0DE9.2020707@resolversystems.com> <350E7D38B6D819428718949920EC23554FF7266AA5@NA-EXMSG-C102.redmond.corp.microsoft.com> <490B34CC.1020607@voidspace.org.uk> <350E7D38B6D819428718949920EC23554FF7266AB3@NA-EXMSG-C102.redmond.corp.microsoft.com> <490B3806.3090100@voidspace.org.uk> Message-ID: <350E7D38B6D819428718949920EC23554FF7266AD0@NA-EXMSG-C102.redmond.corp.microsoft.com> Makes sense - and having the same libraries loaded will certainly reduce any confusion... can you just have sys.path be empty or different for the 2ndary hosted engines? Also if you're using the pre-compiled modules you could actually just remove the compiled loader from sys.meta_path. -----Original Message----- From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, October 31, 2008 9:53 AM To: Discussion of IronPython Subject: Re: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython Dino Viehland wrote: > If you also have those modules living on disk in sys.path - yes. But honestly it is a little scary that you're using modules across ScriptRuntime's and I can't say that I'd advise that as a best practice. Of course I don't know that anything will go wrong either but it might get really confusing... > The basic scenario is that our spreadsheets use a host of our spreadsheet model libraries. If every new document has to import these from scratch then it drastically increases the time (and memory use) associated with creating a new document and doing the first calculation. Of course if importing large amounts of Python code was quicker and used less memory it wouldn't be such an issue. ;-) If a single runtime could have multiple Python engines associated then we could do that, but as far as I can tell creating a new engine from a runtime with an existing engine will always return the existing engine? Though as they are all using the same libraries it seems sensible for them to be shared rather than each document holding an identical copy. If at some point we move to isolate documents using AppDomains then this will obviously change - but the time cost of a new document having to import everything from scratch is a factor in being able to do that. Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, October 31, 2008 9:40 AM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython > > Dino Viehland wrote: > >> We try to import from the file system before we attempt to import from the DLR (which includes both globals & .NET namespaces). So in this case we'll pick up foobar from disk because presumably these 2 engines both share the entry in sys.path where foobar lives. >> >> I think long term this logic is going to move into an importer hook because by CPython 3.1 the import logic may be written entirely in Python. In that case you'd have the ability to re-order the import hooks so you could control the precedence. But for now I think it's by design - we don't want to block potentially valid imports that would work in CPython (e.g. import System :) ). >> >> > > So if we want to pre-populate an engine with modules we *ought* to be > hooking directly into 'sys.modules' of the hosted engines rather than > using runtime.Globals ? > > Michael > > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Friday, October 31, 2008 6:54 AM >> To: Discussion of IronPython >> Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython >> >> Hello guys, >> >> In Resolver One we use the IronPython hosting API from inside IronPython >> code. I've noticed an oddity that is not how I would expect the hosting >> API to behave if I was using it from C#. >> >> My understanding is that the correct way to publish a module (make it >> available for a ScriptEngine to import) is to set it in >> 'engine.Runtime.Globals'. >> >> If I do this from within IronPython code with a module I have already >> imported and then execute an import statement in the engine, the module >> is re-imported (code executed) rather than using the one I have >> published to the runtime globals. >> >> If I have a 'foobar' module that prints when importing, the following >> code prints twice instead of the once I would expect: >> >> import sys >> import clr >> clr.AddReference('IronPython') >> clr.AddReference('Microsoft.Scripting') >> >> from IronPython.Hosting import Python >> from Microsoft.Scripting import SourceCodeKind >> >> import foobar >> >> engine = Python.CreateEngine() >> engine.Runtime.Globals.SetVariable('foobar', sys.modules['foobar']) >> >> source = engine.CreateScriptSourceFromString('import foobar\r\n', >> SourceCodeKind.Statements) >> scope = engine.CreateScope() >> source.Compile().Execute(scope) >> >> >> *However*, if I change the code to not use Runtime.Globals, but instead >> do the following, then the module is only imported once and I get one >> print as expected: >> >> hostedSys = Python.GetSysModule(engine) >> hostedSys.modules['foobar'] = sys.modules['foobar'] >> >> Is there something I have overlooked here? >> >> As a minor supplementary question, how do I get a reference to the >> default ScriptScope on an engine? Is there any performance advantage in >> using the default one, can I replace it, and does replacing it remove >> any performance benefits we might have got? (OK, so strictly speaking >> that wasn't just one question...) >> >> All the best, >> >> Michael Foord >> >> -- >> Michael Foord >> Senior Software Engineer, Resolver Systems Ltd. >> michael.foord at resolversystems.com >> +44 (0) 20 7253 6372 >> >> Try out Resolver One! >> >> 17a Clerkenwell Road, London EC1M 5RD, UK >> VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. >> Registered address: 843 Finchley Road, London NW11 8NA, UK >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ _______________________________________________ Users mailing list Users at lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com From fuzzyman at voidspace.org.uk Fri Oct 31 18:08:36 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 31 Oct 2008 17:08:36 +0000 Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython In-Reply-To: <350E7D38B6D819428718949920EC23554FF7266AD0@NA-EXMSG-C102.redmond.corp.microsoft.com> References: <490B0DE9.2020707@resolversystems.com> <350E7D38B6D819428718949920EC23554FF7266AA5@NA-EXMSG-C102.redmond.corp.microsoft.com> <490B34CC.1020607@voidspace.org.uk> <350E7D38B6D819428718949920EC23554FF7266AB3@NA-EXMSG-C102.redmond.corp.microsoft.com> <490B3806.3090100@voidspace.org.uk> <350E7D38B6D819428718949920EC23554FF7266AD0@NA-EXMSG-C102.redmond.corp.microsoft.com> Message-ID: <490B3B94.5010902@voidspace.org.uk> Dino Viehland wrote: > Makes sense - and having the same libraries loaded will certainly reduce any confusion... can you just have sys.path be empty or different for the 2ndary hosted engines? Also if you're using the pre-compiled modules you could actually just remove the compiled loader from sys.meta_path. > > We allow user's spreadsheets to execute arbitrary code, including importing modules from the filesystem - so I think we're fine leaving the import hooks in place. By the way - I'm very much enjoying porting Resolver One to IronPython 2. Particularly nice is being able to remove workarounds for bugs in IronPython 1 that are now fixed! Many thanks and congratulations. All the best, Michael > -----Original Message----- > From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord > Sent: Friday, October 31, 2008 9:53 AM > To: Discussion of IronPython > Subject: Re: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython > > Dino Viehland wrote: > >> If you also have those modules living on disk in sys.path - yes. But honestly it is a little scary that you're using modules across ScriptRuntime's and I can't say that I'd advise that as a best practice. Of course I don't know that anything will go wrong either but it might get really confusing... >> >> > > The basic scenario is that our spreadsheets use a host of our > spreadsheet model libraries. > > If every new document has to import these from scratch then it > drastically increases the time (and memory use) associated with creating > a new document and doing the first calculation. > > Of course if importing large amounts of Python code was quicker and used > less memory it wouldn't be such an issue. ;-) > > If a single runtime could have multiple Python engines associated then > we could do that, but as far as I can tell creating a new engine from a > runtime with an existing engine will always return the existing engine? > > Though as they are all using the same libraries it seems sensible for > them to be shared rather than each document holding an identical copy. > If at some point we move to isolate documents using AppDomains then this > will obviously change - but the time cost of a new document having to > import everything from scratch is a factor in being able to do that. > > Michael > >> -----Original Message----- >> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >> Sent: Friday, October 31, 2008 9:40 AM >> To: Discussion of IronPython >> Subject: Re: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython >> >> Dino Viehland wrote: >> >> >>> We try to import from the file system before we attempt to import from the DLR (which includes both globals & .NET namespaces). So in this case we'll pick up foobar from disk because presumably these 2 engines both share the entry in sys.path where foobar lives. >>> >>> I think long term this logic is going to move into an importer hook because by CPython 3.1 the import logic may be written entirely in Python. In that case you'd have the ability to re-order the import hooks so you could control the precedence. But for now I think it's by design - we don't want to block potentially valid imports that would work in CPython (e.g. import System :) ). >>> >>> >>> >> So if we want to pre-populate an engine with modules we *ought* to be >> hooking directly into 'sys.modules' of the hosted engines rather than >> using runtime.Globals ? >> >> Michael >> >> >> >>> -----Original Message----- >>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord >>> Sent: Friday, October 31, 2008 6:54 AM >>> To: Discussion of IronPython >>> Subject: [IronPython] IronPython 2: Oddity with Hosting API from within IronPython >>> >>> Hello guys, >>> >>> In Resolver One we use the IronPython hosting API from inside IronPython >>> code. I've noticed an oddity that is not how I would expect the hosting >>> API to behave if I was using it from C#. >>> >>> My understanding is that the correct way to publish a module (make it >>> available for a ScriptEngine to import) is to set it in >>> 'engine.Runtime.Globals'. >>> >>> If I do this from within IronPython code with a module I have already >>> imported and then execute an import statement in the engine, the module >>> is re-imported (code executed) rather than using the one I have >>> published to the runtime globals. >>> >>> If I have a 'foobar' module that prints when importing, the following >>> code prints twice instead of the once I would expect: >>> >>> import sys >>> import clr >>> clr.AddReference('IronPython') >>> clr.AddReference('Microsoft.Scripting') >>> >>> from IronPython.Hosting import Python >>> from Microsoft.Scripting import SourceCodeKind >>> >>> import foobar >>> >>> engine = Python.CreateEngine() >>> engine.Runtime.Globals.SetVariable('foobar', sys.modules['foobar']) >>> >>> source = engine.CreateScriptSourceFromString('import foobar\r\n', >>> SourceCodeKind.Statements) >>> scope = engine.CreateScope() >>> source.Compile().Execute(scope) >>> >>> >>> *However*, if I change the code to not use Runtime.Globals, but instead >>> do the following, then the module is only imported once and I get one >>> print as expected: >>> >>> hostedSys = Python.GetSysModule(engine) >>> hostedSys.modules['foobar'] = sys.modules['foobar'] >>> >>> Is there something I have overlooked here? >>> >>> As a minor supplementary question, how do I get a reference to the >>> default ScriptScope on an engine? Is there any performance advantage in >>> using the default one, can I replace it, and does replacing it remove >>> any performance benefits we might have got? (OK, so strictly speaking >>> that wasn't just one question...) >>> >>> All the best, >>> >>> Michael Foord >>> >>> -- >>> Michael Foord >>> Senior Software Engineer, Resolver Systems Ltd. >>> michael.foord at resolversystems.com >>> +44 (0) 20 7253 6372 >>> >>> Try out Resolver One! >>> >>> 17a Clerkenwell Road, London EC1M 5RD, UK >>> VAT No.: GB 893 5643 79 Registered in England and Wales as company number 5467329. >>> Registered address: 843 Finchley Road, London NW11 8NA, UK >>> >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> _______________________________________________ >>> Users mailing list >>> Users at lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >> -- >> http://www.ironpythoninaction.com/ >> >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> Users mailing list >> Users at lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> > > > -- > http://www.ironpythoninaction.com/ > > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ From dan.eloff at gmail.com Fri Oct 31 20:29:39 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Fri, 31 Oct 2008 14:29:39 -0500 Subject: [IronPython] How can you create set/frozenset from C# ? In-Reply-To: <490A3B6D.4070309@voidspace.org.uk> References: <4817b6fc0810181255o40781323uaf62e362f8110d00@mail.gmail.com> <490A3B6D.4070309@voidspace.org.uk> Message-ID: <4817b6fc0810311229j5ac39fa3ne2e2aac70c4aa1f5@mail.gmail.com> On Thu, Oct 30, 2008 at 5:55 PM, Michael Foord wrote: > SetCollection has a public constructor. > > If you need the CodeContext for __new__ then you can get one like this: > > LanguageContext language = HostingHelpers.GetLanguageContext(engine); > CodeContext co = new CodeContext(new Scope(), language) > Thanks, that's exactly what I was looking for. Cheers, -Dan From dan.eloff at gmail.com Fri Oct 31 21:03:25 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Fri, 31 Oct 2008 15:03:25 -0500 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <97764E78-94CA-429C-BE01-3006D2244573@gmail.com> References: <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> <9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com> <5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com> <4909FAE7.4000309@voidspace.org.uk> <5b0248170810301153y448e7236yb2069a0c65174ea3@mail.gmail.com> <490A1DAA.3010200@voidspace.org.uk> <97764E78-94CA-429C-BE01-3006D2244573@gmail.com> Message-ID: <4817b6fc0810311303x6596ad54ycfe72294eb608c3b@mail.gmail.com> On Thu, Oct 30, 2008 at 5:27 PM, Kenneth Miller wrote: > So, > Before I get to into this, does this project hold merit for anyone but > myself? Would anyone outside of Seo and I like to see it move forward. I > like to spend my time on worthwhile adventures. Like I said before, the main > motivation here is to have access to common python standard library > operations (even if mapped to .NET) in Silverlight apps without having to > include the python standard library itself. > Regards, > Ken Anything that can improve my load times in Silverlight is very interesting to me. I would definately use it, and if I'm using it, I'd be contributing as well everytime I encounter a bug, or missing functionality. -Dan From xkenneth at gmail.com Fri Oct 31 21:05:40 2008 From: xkenneth at gmail.com (Kenneth Miller) Date: Fri, 31 Oct 2008 15:05:40 -0500 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <4817b6fc0810311303x6596ad54ycfe72294eb608c3b@mail.gmail.com> References: <0CD70677-B1A8-4FE1-ADBE-147C1DDA1B96@gmail.com> <5b0248170810290019s2a6ec20bm2a2fda00819a96f1@mail.gmail.com> <9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com> <5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com> <4909FAE7.4000309@voidspace.org.uk> <5b0248170810301153y448e7236yb2069a0c65174ea3@mail.gmail.com> <490A1DAA.3010200@voidspace.org.uk> <97764E78-94CA-429C-BE01-3006D2244573@gmail.com> <4817b6fc0810311303x6596ad54ycfe72294eb608c3b@mail.gmail.com> Message-ID: <17CF84DE-2B94-4711-878C-B1D0E2C6CDDA@gmail.com> Dan, Thanks for the encouragement, it's much appreciated. If you don't mind discussing off the list, I'd love to ask you some questions about silverlight and see what you're doing with it. Regards, Ken On Oct 31, 2008, at 3:03 PM, Dan Eloff wrote: > On Thu, Oct 30, 2008 at 5:27 PM, Kenneth Miller > wrote: >> So, >> Before I get to into this, does this project hold merit for >> anyone but >> myself? Would anyone outside of Seo and I like to see it move >> forward. I >> like to spend my time on worthwhile adventures. Like I said before, >> the main >> motivation here is to have access to common python standard library >> operations (even if mapped to .NET) in Silverlight apps without >> having to >> include the python standard library itself. >> Regards, >> Ken > > Anything that can improve my load times in Silverlight is very > interesting to me. I would definately use it, and if I'm using it, I'd > be contributing as well everytime I encounter a bug, or missing > functionality. > > -Dan > _______________________________________________ > Users mailing list > Users at lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.eloff at gmail.com Fri Oct 31 22:06:20 2008 From: dan.eloff at gmail.com (Dan Eloff) Date: Fri, 31 Oct 2008 16:06:20 -0500 Subject: [IronPython] Python Standard Library in IronPython In-Reply-To: <17CF84DE-2B94-4711-878C-B1D0E2C6CDDA@gmail.com> References: <9F9C3C0C-9285-43F5-8518-5622322BC379@gmail.com> <5b0248170810290919m71de1d45i7af9e2b571b78976@mail.gmail.com> <4909FAE7.4000309@voidspace.org.uk> <5b0248170810301153y448e7236yb2069a0c65174ea3@mail.gmail.com> <490A1DAA.3010200@voidspace.org.uk> <97764E78-94CA-429C-BE01-3006D2244573@gmail.com> <4817b6fc0810311303x6596ad54ycfe72294eb608c3b@mail.gmail.com> <17CF84DE-2B94-4711-878C-B1D0E2C6CDDA@gmail.com> Message-ID: <4817b6fc0810311406y363a20a3u689dc900993eb286@mail.gmail.com> On Fri, Oct 31, 2008 at 3:05 PM, Kenneth Miller wrote: > Dan, > Thanks for the encouragement, it's much appreciated. If you don't mind > discussing off the list, I'd love to ask you some questions about > silverlight and see what you're doing with it. > Regards, > Ken Nothing I'm working on is top secret. Since January I've been working full time on a massively multiplayer turn-based strategy game. Initially I was using html/ajax for the client and CPython/django for the backend. In May I discovered the silverlight 2 beta, grabbed an early IronPython 2 alpha, and started porting the client. It was a gamble that set me back, but it's paying off now. Having Python on server and client means I can share code, and I can very efficiently transfer python data structures in binary format between server and client over HTTP. This makes new things possible. For example, at startup I send 100K of binary data to the client, that's the equivalent of almost 2mb of JSON. The real product is not the game itself, but the game engine as a platform for creating other games. I already have a group of fans very serious about building a Star Wars game on the engine. If they follow through on their plans it could be more visually impressive than my game. If you have any questions, just ask. -Dan From fuzzyman at voidspace.org.uk Fri Oct 31 23:12:52 2008 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Fri, 31 Oct 2008 22:12:52 +0000 Subject: [IronPython] Length Hint Not Used Message-ID: <490B82E4.60905@voidspace.org.uk> Hello, Well, I guess this isn't a bug (its only a hint) - but IronPython doesn't use length hint. :-) CPython >>> class X(object): ... def __iter__(self): ... return iter([1,2,3]) ... def __length_hint__(self): ... print 'length hint' ... return 3 ... >>> x = X() >>> list(x) length hint [1, 2, 3] IronPython >>> class X(object): ... def __iter__(self): ... return iter([1,2,3]) ... def __length_hint__(self): ... print 'length hint' ... return 3 ... >>> x = X() >>> list(x) [1, 2, 3] >>> CPython uses it as an optimisation to preallocate space for the list. You can bet somebody, somewhere is writing code that depends on length hint being called... Actually probably not, but it's one of those methods like '__reversed__' and '__missing__' that I've only recently discovered. I was impressed that IronPython supported '__missing__' by the way. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog From curt at hagenlocher.org Fri Oct 31 23:18:20 2008 From: curt at hagenlocher.org (Curt Hagenlocher) Date: Fri, 31 Oct 2008 15:18:20 -0700 Subject: [IronPython] Length Hint Not Used In-Reply-To: <490B82E4.60905@voidspace.org.uk> References: <490B82E4.60905@voidspace.org.uk> Message-ID: The CPython test suite says specifically # note: this is an internal undocumented API # don't rely on it in your own programs so I don't feel too bad about it. :) On Fri, Oct 31, 2008 at 3:12 PM, Michael Foord wrote: > Hello, > > Well, I guess this isn't a bug (its only a hint) - but IronPython doesn't > use length hint. :-) > > CPython > >>> class X(object): > ... def __iter__(self): > ... return iter([1,2,3]) > ... def __length_hint__(self): > ... print 'length hint' > ... return 3 > ... > >>> x = X() > >>> list(x) > length hint > [1, 2, 3] > > IronPython > >>> class X(object): > ... def __iter__(self): > ... return iter([1,2,3]) > ... def __length_hint__(self): > ... print 'length hint' > ... return 3 > ... > >>> x = X() > >>> list(x) > [1, 2, 3] > >>> > > CPython uses it as an optimisation to preallocate space for the list. > > You can bet somebody, somewhere is writing code that depends on length hint > being called... Actually probably not, but it's one of those methods like > '__reversed__' and '__missing__' that I've only recently discovered. I was > impressed that IronPython supported '__missing__' by the way. > > Michael > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > > _______________________________________________ > 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: