From fuzzyman at voidspace.org.uk Thu Apr 1 01:34:10 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 01 Apr 2010 00:34:10 +0100
Subject: [IronPython] Gestalt,
IronPython in Silverlight and embedded xaml
In-Reply-To: <1B42307CD4AADD438CDDA2FE1121CC92173128F2@TK5EX14MBXC136.redmond.corp.microsoft.com>
References: <4BB2915D.6050309@voidspace.org.uk>
<1B42307CD4AADD438CDDA2FE1121CC92173128F2@TK5EX14MBXC136.redmond.corp.microsoft.com>
Message-ID: <4BB3DBF2.2060502@voidspace.org.uk>
On 31/03/2010 03:06, Jimmy Schementi wrote:
>> I still need to package my app into a zip file and serve it locally (doesn't work from the filesystem)
>>
> Michael, what do you exactly mean by this? You need your app to run out of browser?
>
>
I mean that if I develop in an html file I can't view it from the
filesystem in a browser but must still have a locally running server for
the scripts to run.
>> It doesn't seem to me that embedded xaml is working
>>
> First of all, docs/spec issue: the current online bits only support application/xml+xaml, and the docs have application/xaml+xml.
oferchrisakes. Yes, switching solved the problem.
This leads into an interesting point - the docs show the following as
the public url to use for dlr.js:
http://gestalt.ironpython.net/dlr-latest.js
This means any backwards incompatible changes are *guaranteed* to break
apps using it. :-) What are needed are versioned URLs so that you can
specify precisely which version to use. Are these available, I couldn't
find them in the docs but I may just not be looking in the right place.
> The release that will be online in a few days supports both. After correcting that you will get a SL control created on the page; here's the exact HTML (with a Text attribute added to the TextBlock to make it obvious that it worked):
>
>
>
>
>
>
>
>
>
>
> Then, if you add the following Python script-tag after the XAML script tag, it will update the text:
>
>
>
> Note the *class="inlineXAML"* attribute; if you did not include this, the code would run against a different Silverlight control than the one created by your *id="inlineXAML"* tag. In fact, it would run against a SL control that is essentially hidden, so app.RootVisual would be None. In short, giving a XAML script-tag an ID lets you pick the Python script-tags that will run against it by setting their class attribute to the same value.
>
> I'll update the docs accordingly...
>
>
Thanks for your help. I wasn't using the class attribute which would
have caused me problems even if I had been using the right xml type
declaration. I did think that the docs said all un-scoped scripts were
run against the default control, but using an explicit scope is no problem.
Michael
> ~Jimmy
> _______________________________________________
> 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
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
From Jimmy.Schementi at microsoft.com Thu Apr 1 05:04:14 2010
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Thu, 1 Apr 2010 03:04:14 +0000
Subject: [IronPython] Gestalt,
IronPython in Silverlight and embedded xaml
In-Reply-To: <4BB3DBF2.2060502@voidspace.org.uk>
References: <4BB2915D.6050309@voidspace.org.uk>
<1B42307CD4AADD438CDDA2FE1121CC92173128F2@TK5EX14MBXC136.redmond.corp.microsoft.com>
<4BB3DBF2.2060502@voidspace.org.uk>
Message-ID: <1B42307CD4AADD438CDDA2FE1121CC9217315993@TK5EX14MBXC136.redmond.corp.microsoft.com>
> I mean that if I develop in an html file I can't view it from the filesystem in a
> browser but must still have a locally running server for the scripts to run.
Yes, this is true today; I think mainly because dlr.xap depends on downloading Microsoft.Scripting.slvx at startup, and that must be failing from the file-system. If the assemblies were in the XAP, I'm pretty sure it'll work, and I think that's what will happen in the future. http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=26672.
Though, do you really not have a machine that has a web-server running on it anyway, be it Apache or IIS? I like that it doesn't *require* me to use Chiron.
> This means any backwards incompatible changes are *guaranteed* to break
> apps using it. :-) What are needed are versioned URLs so that you can specify
> precisely which version to use.
The first "Note" in the docs addresses this: http://ironpython.net/browser/docs.html#setup
"Note: using the gestalt.ironpython.net version is preferred, especially in production. However, please pick a specific version (like dlr-20100305.js, rather than dlr-latest.js), as this will ensure your application keeps working between releases; dlr-latest.js will always point to the most recent version."
But I guess that should be called out a bit more obviously?
> Are these [other versions] available, I couldn't find them in the
> docs but I may just not be looking in the right place.
The online versions aren't enumerated anywhere, as there's just two:
http://gestalt.ironpython.net/dlr-20100305.js
http://gestalt.ironpython.net/dlr-20091120.js
For the next release I can start maintaining this list on the website.
> I did think that the docs said all un-scoped scripts were run against the default
> control, but using an explicit scope is no problem.
Yes, that's true; un-scoped scripts are run against the "default control", which is defined as the control automatically added to the page when dlr*.js is run, and has a width/height of 1px; basically for DOM-only apps. If you have a XAML script-tag though, that DOM-only control is still added to the page, forcing you to always scope your script-tag if you're using XAML. I guess you assumed the "default control" meant the "first control"? I'm a bit unsure about what the right behavior should be, so I just left it as-is; let me know what you think: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=26673
~js
From avinhan at gmail.com Thu Apr 1 09:59:36 2010
From: avinhan at gmail.com (Aravin)
Date: Thu, 1 Apr 2010 15:59:36 +0800
Subject: [IronPython] pyFlakes pySmell
In-Reply-To: <4BAB6AB5.1090205@voidspace.org.uk>
References:
<4BAB4495.1050206@voidspace.org.uk>
<4BAB6AB5.1090205@voidspace.org.uk>
Message-ID:
Hi Guys,
Thanks for the information on this.
Jeff, I tried to download and compiler your _ast library, but it's giving
me errors.
Error 1 'IronPython.Runtime.PythonModule' does not contain a definition for
'TryGetName' and no extension method 'TryGetName' accepting a first argument
of type 'IronPython.Runtime.PythonModule' could be found (are you missing a
using directive or an assembly reference?) _ast\_ast.cs 114 50 _ast
Error 2 The best overloaded method match for
'IronPython.Runtime.CodeContext.CodeContext(IronPython.Runtime.PythonDictionary,
IronPython.Runtime.ModuleContext)' has some invalid
arguments _ast\_ast.cs 119 35 _ast
Error 3 Argument '2': cannot convert from 'IronPython.Runtime.PythonContext'
to 'IronPython.Runtime.ModuleContext' _ast\_ast\_ast.cs 119 75 _ast
I'm using IronPython 2.6RC1. Am I doing something wrong?
Also, if anyone is interested, I updated the compiler package found in FePy
to work with IronPython 2.6RC1.
I'm able to run pyFlakes on IronPython using it (also tried pySmell and it
works so far).
I'm fixing up errors as I encounter them. Is there any test cases that I can
run to make sure that the implementation works?
So if anyone wants to use the compiler package, let me know and I can put it
up on codeplex or something.
Is there a way to convert the compiler.ast to _ast?
Thanks,
Aravin
On Thu, Mar 25, 2010 at 9:52 PM, Michael Foord wrote:
> On 25/03/2010 13:44, Jeff Hardy wrote:
>
>> On Thu, Mar 25, 2010 at 5:10 AM, Michael Foord
>> wrote:
>>
>>
>>> They almost certainly use the compiler / ast modules that aren't
>>> available
>>> for IronPython. You can ship CPython as part of your application though,
>>> without needing it to be installed.
>>>
>>>
>> http://bitbucket.org/jdhardy/_ast/
>>
>> There's one compiler error under 2.6 (a function is missing/renamed);
>> I just haven't had a chance to figure it out.
>>
>> That said, if pyflakes/pysmell use 'compiler' instead of 'ast', you're
>> probably hooped. Compiler is unlikely to ever be supported.
>>
>>
>
> I think FePy used to have support for the compiler module, but I'm having a
> hard time figuring out where that was implemented.
>
> All the best,
>
> Michael
>
>
> - Jeff
>> _______________________________________________
>> 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
>
> READ CAREFULLY. By accepting and reading this email you agree, on behalf of
> your employer, to release me from all obligations and waivers arising from
> any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
> shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
> non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have
> entered into with your employer, its partners, licensors, agents and
> assigns, in perpetuity, without prejudice to my ongoing rights and
> privileges. You further represent that you have the authority to release me
> from any BOGUS AGREEMENTS on behalf of your employer.
>
>
> _______________________________________________
> 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 cgencer at gmail.com Thu Apr 1 10:59:36 2010
From: cgencer at gmail.com (Can Gencer)
Date: Thu, 1 Apr 2010 10:59:36 +0200
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
Message-ID:
Hello,
I am trying to use CherryPy through IronPython. I am using a custom
web server written in C# and I am using the NWSGI handler available
here (http://nwsgi.codeplex.com/) with some modifications to work with
my custom web server instead of IIS.
Everything works after some tweaking done to CherryPy. I re-use the
application callable that is retrieved from the main script that is
compiled into CompiledCode . However the memory usage never seems to
go down, and goes up with every HTTP request, even if I force
GC.Collect() after every request.
The WSGI handler is invoking the delegate returned from the main
python script with some parameters that are standard in WSGI, such as
a start_response delegate Everytime a request is made, the handler
will invoke the application callable that is stored as a reference.
CherryPy also has a built in web server that is using WSGI that can be
invoked with CPython. When testing that, there are no memory leaks.
Any ideas on what the problem could be?
From fuzzyman at voidspace.org.uk Thu Apr 1 13:44:03 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 01 Apr 2010 12:44:03 +0100
Subject: [IronPython] Gestalt,
IronPython in Silverlight and embedded xaml
In-Reply-To: <1B42307CD4AADD438CDDA2FE1121CC9217315993@TK5EX14MBXC136.redmond.corp.microsoft.com>
References: <4BB2915D.6050309@voidspace.org.uk>
<1B42307CD4AADD438CDDA2FE1121CC92173128F2@TK5EX14MBXC136.redmond.corp.microsoft.com>
<4BB3DBF2.2060502@voidspace.org.uk>
<1B42307CD4AADD438CDDA2FE1121CC9217315993@TK5EX14MBXC136.redmond.corp.microsoft.com>
Message-ID: <4BB48703.1010005@voidspace.org.uk>
On 01/04/2010 04:04, Jimmy Schementi wrote:
>> I mean that if I develop in an html file I can't view it from the filesystem in a
>> browser but must still have a locally running server for the scripts to run.
>>
> Yes, this is true today; I think mainly because dlr.xap depends on downloading Microsoft.Scripting.slvx at startup, and that must be failing from the file-system. If the assemblies were in the XAP, I'm pretty sure it'll work, and I think that's what will happen in the future. http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=26672.
>
> Though, do you really not have a machine that has a web-server running on it anyway, be it Apache or IIS? I like that it doesn't *require* me to use Chiron.
>
I *never* have a machine running IIS and my Windows VM doesn't have
Apache setup on it - so as far as I'm concerned I *do* still need Chiron
running. I can see that being able to use an alternative server is an
advantage though.
>
>> This means any backwards incompatible changes are *guaranteed* to break
>> apps using it. :-) What are needed are versioned URLs so that you can specify
>> precisely which version to use.
>>
> The first "Note" in the docs addresses this:http://ironpython.net/browser/docs.html#setup
>
>
Ah - I just missed that note. Now you mention it, it is pretty obvious,
so just me being dense. :-)
> "Note: using the gestalt.ironpython.net version is preferred, especially in production. However, please pick a specific version (like dlr-20100305.js, rather than dlr-latest.js), as this will ensure your application keeps working between releases; dlr-latest.js will always point to the most recent version."
>
> But I guess that should be called out a bit more obviously?
>
>
A list of available versions would be nice, preferably specifying which
version of IronPython / IronRuby they use and a list of changes in each
version.
>> Are these [other versions] available, I couldn't find them in the
>> docs but I may just not be looking in the right place.
>>
> The online versions aren't enumerated anywhere, as there's just two:
>
> http://gestalt.ironpython.net/dlr-20100305.js
> http://gestalt.ironpython.net/dlr-20091120.js
>
> For the next release I can start maintaining this list on the website.
>
>
Great.
>> I did think that the docs said all un-scoped scripts were run against the default
>> control, but using an explicit scope is no problem.
>>
> Yes, that's true; un-scoped scripts are run against the "default control", which is defined as the control automatically added to the page when dlr*.js is run, and has a width/height of 1px; basically for DOM-only apps. If you have a XAML script-tag though, that DOM-only control is still added to the page, forcing you to always scope your script-tag if you're using XAML. I guess you assumed the "default control" meant the "first control"? I'm a bit unsure about what the right behavior should be, so I just left it as-is; let me know what you think: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=26673
>
Ok. I don't like the *idea* of an extra invisible Silverlight control
but am prepared to take your word that it isn't an issue in practise. My
'skimming' (i.e. not reading properly) of the docs implied to me that
all unscoped scripts would run in the same control - but in fact if you
have a xaml script that *has* to create a new control. So unscoped
Python scripts all run in the default (invisible) control and unscoped
xaml creates a new control that isn't then used by code.
I don't have concrete suggestions for making this clearer - other than
to strongly recommend in the docs that all code / xaml is scoped.
Michael
> ~js
>
>
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
From fuzzyman at voidspace.org.uk Thu Apr 1 13:47:29 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 01 Apr 2010 12:47:29 +0100
Subject: [IronPython] pyFlakes pySmell
In-Reply-To:
References: <4BAB4495.1050206@voidspace.org.uk> <4BAB6AB5.1090205@voidspace.org.uk>
Message-ID: <4BB487D1.2040704@voidspace.org.uk>
On 01/04/2010 08:59, Aravin wrote:
> [snip...]
> Also, if anyone is interested, I updated the compiler package found in
> FePy to work with IronPython 2.6RC1.
> I'm able to run pyFlakes on IronPython using it (also tried pySmell
> and it works so far).
> I'm fixing up errors as I encounter them. Is there any test cases that
> I can run to make sure that the implementation works?
> So if anyone wants to use the compiler package, let me know and I can
> put it up on codeplex or something.
If you could make this publicly available somewhere that would be great.
There are quite a few projects that require the compiler package.
All the best,
Michael Foord
> Is there a way to convert the compiler.ast to _ast?
> Thanks,
> Aravin
> On Thu, Mar 25, 2010 at 9:52 PM, Michael Foord
> > wrote:
>
> On 25/03/2010 13:44, Jeff Hardy wrote:
>
> On Thu, Mar 25, 2010 at 5:10 AM, Michael Foord
> >
> wrote:
>
> They almost certainly use the compiler / ast modules that
> aren't available
> for IronPython. You can ship CPython as part of your
> application though,
> without needing it to be installed.
>
> http://bitbucket.org/jdhardy/_ast/
>
> There's one compiler error under 2.6 (a function is
> missing/renamed);
> I just haven't had a chance to figure it out.
>
> That said, if pyflakes/pysmell use 'compiler' instead of
> 'ast', you're
> probably hooped. Compiler is unlikely to ever be supported.
>
>
> I think FePy used to have support for the compiler module, but I'm
> having a hard time figuring out where that was implemented.
>
> All the best,
>
> Michael
>
>
> - Jeff
> _______________________________________________
> 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
>
> READ CAREFULLY. By accepting and reading this email you agree, on
> behalf of your employer, to release me from all obligations and
> waivers arising from any and all NON-NEGOTIATED agreements,
> licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
> confidentiality, non-disclosure, non-compete and acceptable use
> policies (?BOGUS AGREEMENTS?) that I have entered into with your
> employer, its partners, licensors, agents and assigns, in
> perpetuity, without prejudice to my ongoing rights and privileges.
> You further represent that you have the authority to release me
> from any BOGUS AGREEMENTS on behalf of your employer.
>
>
> _______________________________________________
> 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
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jdhardy at gmail.com Thu Apr 1 17:15:10 2010
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 1 Apr 2010 09:15:10 -0600
Subject: [IronPython] pyFlakes pySmell
In-Reply-To:
References:
<4BAB4495.1050206@voidspace.org.uk>
<4BAB6AB5.1090205@voidspace.org.uk>
Message-ID:
On Thu, Apr 1, 2010 at 1:59 AM, Aravin wrote:
> Hi Guys,
>
> Thanks for the information on this.
>
> Jeff, I tried to download and compiler your _ast library, but it's giving
> me?errors.
>
> ...
>
> I'm using IronPython 2.6RC1. Am I doing something wrong?
Probably not. I haven't gotten it working with the latest 2.6 releases
(I think it worked with Beta 1 or something like that). I'm pretty
sure it's a simple fix, but I just haven't got around to it.
- Jeff
From davidjensen at usa.net Thu Apr 1 17:47:06 2010
From: davidjensen at usa.net (David Jensen)
Date: Thu, 01 Apr 2010 11:47:06 -0400
Subject: [IronPython] ironpython window in Microsoft Office Application
Message-ID: <844oDaPUg3728S18.1270136826@cmsweb18.cms.usa.net>
Can an IronPython interpreter window be placed in an office application, such
as Outlook 2007? Outlook 2007 is quite customizable. The forms can be
modified. An IronPython interpreter window would be more useful than VBA,
since VBA is not interactive (I have not used it much). I have VS 2008
Professional. Can this be used? Can the IP window be put in without it? I am
sure I run IP or CP outside of office using com objects.
David Jensen
From merllab at microsoft.com Thu Apr 1 17:53:34 2010
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Thu, 1 Apr 2010 08:53:34 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <7028bf07-2522-4965-b334-a121ea24663a@tk5-exsmh-c101.redmond.corp.microsoft.com>
This is an automated email letting you know that sources
have recently been pushed out. You can download these newer
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/65175.
ADDED SOURCES
$/IronPython/IronPython_Main/Src/Tests/pyc/stdmodules_ok.ps1
DELETED SOURCES
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Runtime/DynamicStackFrame.cs
MODIFIED SOURCES
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/ControlFlowInstructions.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/InstructionList.cs
$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/AstMethods.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Generation/Snippets.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonDynamicStackFrame.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/ErrorFormatter.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/Properties/AssemblyInfo.cs
$/IronPython/IronPython_Main/Src/IronPython/Compiler/PythonScriptCode.cs
$/IronPython/IronPython_Main/Src/IronPython/Compiler/RuntimeScriptCode.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonDictionary.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/Exceptions/PythonExceptions.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonTypeUserDescriptorSlot.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/Types/PythonType.cs
$/IronPython/IronPython_Main/Src/AssemblyVersion.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Properties/AssemblyInfo.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Microsoft.Dynamic.csproj
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Runtime/ExceptionHelpers.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Interpreter.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightCompiler.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/UserTypeOps.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/WeakRef.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/Generator.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/List.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonContext.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/Importer.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/ObjectAttributesAdapter.cs
$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/WithStatement.cs
$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/TryStatement.cs
$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/ScopeStatement.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Utils/ArrayUtils.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Runtime/ScriptingRuntimeHelpers.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Debugging/AssemblyInfo.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Properties/ExtensionAssemblyInfo.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Hosting/ExceptionOperations.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Microsoft.Scripting.csproj
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Properties/AssemblyInfo.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Hosting/TokenCategorizer.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/DynamicStackFrame.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Properties/AssemblyInfo.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/LanguageContext.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting/Runtime/TokenizerService.cs
$/IronPython/IronPython_Main/Src/Tests/pyc/stdmodules_ok.ps1
$/IronPython/IronPython_Main/Src/Tests/pyc/test_pyc.ps1
CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 1708300
Date: 3/31/2010 8:52:23 PM
Cleans up exception handling in IronPython to fix a source of memory leak bugs. Improves the interpreter?s support for rethrowing exceptions. Adds support for getting DynamicStackFrames via the hosting APIs ExceptionOperations class rather than going to some static helper.
The big change here is that IronPython now adds the stack frames that an exception has propagated through via try/catch blocks instead of storing them in a ThreadStatic variable and attaching them when the exception is caught. We used to do the thread static because we used to frequently use try/fault blocks ? but when we switched to using DynamicMethod?s for all of our optimized code gen we never almost no opportunities to use try/fault blocks ? not that we have code paths that would use them even if we did. Because we always have try/catch?s we may as well take care of this to clean up the memory leaks which have been reported by users. This also means we no longer need to clear stack frames throughout the code base.
This also adds a new hosting API to get the dynamic stack frames ? we currently have a static API in ScriptingRuntimeHelpers that people have been using. Instead I?ve moved this to ExceptionOperations and have a virtual on LanguageContext which languages can override.
This pulls a bunch of code from ScriptingRuntimeHelpers into PythonExceptions as we?re the only consumer (this is a post-2.6 change so I?m opening the flood gates on breaking changes).
Also adds support for proper rethrow in the interpreter. Whenever we take an exception we now go into a HandleException method. This method can recurse for each exception which is caught (we?re limited to the number of throws actually available in the exception handler) and returns when the exception is done being handled. If we encounter a rethrow we now have the exception on the stack in our catch block so we can properly re-throw it.
(Shelveset: EhCleanupFinal3;REDMOND\dinov | SNAP CheckinId: 10621)
--------------------------------------------------------------------------------
Changeset Id: 1708006
Date: 3/31/2010 5:19:57 PM
Added a fairly thorough regression for http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=26593. We now precompile the entire CPython standard library for every
checkin (as a test).
(Shelveset: PRECOMPILE_TEST;REDMOND\dfugate | SNAP CheckinId: 10617)
--------------------------------------------------------------------------------
Changeset Id: 1708300
Date: 3/31/2010 8:52:23 PM
Cleans up exception handling in IronPython to fix a source of memory leak bugs. Improves the interpreter?s support for rethrowing exceptions. Adds support for getting DynamicStackFrames via the hosting APIs ExceptionOperations class rather than going to some static helper.
The big change here is that IronPython now adds the stack frames that an exception has propagated through via try/catch blocks instead of storing them in a ThreadStatic variable and attaching them when the exception is caught. We used to do the thread static because we used to frequently use try/fault blocks ? but when we switched to using DynamicMethod?s for all of our optimized code gen we never almost no opportunities to use try/fault blocks ? not that we have code paths that would use them even if we did. Because we always have try/catch?s we may as well take care of this to clean up the memory leaks which have been reported by users. This also means we no longer need to clear stack frames throughout the code base.
This also adds a new hosting API to get the dynamic stack frames ? we currently have a static API in ScriptingRuntimeHelpers that people have been using. Instead I?ve moved this to ExceptionOperations and have a virtual on LanguageContext which languages can override.
This pulls a bunch of code from ScriptingRuntimeHelpers into PythonExceptions as we?re the only consumer (this is a post-2.6 change so I?m opening the flood gates on breaking changes).
Also adds support for proper rethrow in the interpreter. Whenever we take an exception we now go into a HandleException method. This method can recurse for each exception which is caught (we?re limited to the number of throws actually available in the exception handler) and returns when the exception is done being handled. If we encounter a rethrow we now have the exception on the stack in our catch block so we can properly re-throw it.
(Shelveset: EhCleanupFinal3;REDMOND\dinov | SNAP CheckinId: 10621)
From dinov at microsoft.com Thu Apr 1 19:20:59 2010
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 1 Apr 2010 17:20:59 +0000
Subject: [IronPython] ironpython window in Microsoft Office Application
In-Reply-To: <844oDaPUg3728S18.1270136826@cmsweb18.cms.usa.net>
References: <844oDaPUg3728S18.1270136826@cmsweb18.cms.usa.net>
Message-ID: <1A472770E042064698CB5ADC83A12ACD394E4662@TK5EX14MBXC118.redmond.corp.microsoft.com>
David Jensen:
> Can an IronPython interpreter window be placed in an office application, such
> as Outlook 2007? Outlook 2007 is quite customizable. The forms can be
> modified. An IronPython interpreter window would be more useful than VBA,
> since VBA is not interactive (I have not used it much). I have VS 2008
> Professional. Can this be used? Can the IP window be put in without it? I am
> sure I run IP or CP outside of office using com objects.
This can be done but you'll need to implement the REPL window or find an
existing one out there. There are plenty of WPF based REPL windows which have
been developed (in particular for Silverlight) so you might be able to borrow
the code from there. Once you do that you just need to put pieces of the Office
object model in a ScriptScope so that the scripts can access them.
From slide.o.mix at gmail.com Thu Apr 1 19:22:15 2010
From: slide.o.mix at gmail.com (Slide)
Date: Thu, 1 Apr 2010 10:22:15 -0700
Subject: [IronPython] ironpython window in Microsoft Office Application
In-Reply-To: <844oDaPUg3728S18.1270136826@cmsweb18.cms.usa.net>
References: <844oDaPUg3728S18.1270136826@cmsweb18.cms.usa.net>
Message-ID:
On Thu, Apr 1, 2010 at 8:47 AM, David Jensen wrote:
> Can an IronPython interpreter window be placed in an office application, such
> as Outlook 2007? Outlook 2007 is quite customizable. The forms can be
> modified. An IronPython interpreter window would be more useful than VBA,
> since VBA is not interactive (I have not used it much). I have ?VS 2008
> Professional. Can this be used? Can the IP window be put in without it? I am
> sure I run IP or CP outside of office using com objects.
>
>
> David Jensen
>
This sounds like a great idea!
From dinov at microsoft.com Thu Apr 1 19:27:12 2010
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 1 Apr 2010 17:27:12 +0000
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
Message-ID: <1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
Can Gencer wrote:
> I am trying to use CherryPy through IronPython. I am using a custom
> web server written in C# and I am using the NWSGI handler available
> here (http://nwsgi.codeplex.com/) with some modifications to work with
> my custom web server instead of IIS.
>
> Everything works after some tweaking done to CherryPy. I re-use the
> application callable that is retrieved from the main script that is
> compiled into CompiledCode . However the memory usage never seems to
> go down, and goes up with every HTTP request, even if I force
> GC.Collect() after every request.
>
> The WSGI handler is invoking the delegate returned from the main
> python script with some parameters that are standard in WSGI, such as
> a start_response delegate Everytime a request is made, the handler
> will invoke the application callable that is stored as a reference.
>
> CherryPy also has a built in web server that is using WSGI that can be
> invoked with CPython. When testing that, there are no memory leaks.
>
> Any ideas on what the problem could be?
The one issue that I know people have been running into is related to
exception handling leaking memory. 2.6.1 has some improvements to
prevent this from happening but it still might happen. 2.7 will have
a permanent fix for this (which is available on CodePlex in as of this
morning).
To see if this is the problem you can check ExceptionHelpers.DynamicStackFrames
and see if it's growing larger. You can set it to null if it is.
If that's not it I can give some suggestions on how to debug it but
usually involes windbg.
From jdhardy at gmail.com Thu Apr 1 20:08:22 2010
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 1 Apr 2010 12:08:22 -0600
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
Message-ID:
On Thu, Apr 1, 2010 at 2:59 AM, Can Gencer wrote:
> Hello,
Hi Can,
You are, to my knowledge, the first person besides me to use NWSGI for
anything, so thank you!
> Everything works after some tweaking done to CherryPy. I re-use the
> application callable that is retrieved from the main script that is
> compiled into CompiledCode . However the memory usage never seems to
> go down, and goes up with every HTTP request, even if I force
> GC.Collect() after every request.
I haven't done any stress testing of NWSGI because my uses don't have
any where near the traffic to need it :). It's quite possible that I'm
holding to references to something (code objects maybe?) past there
usefulness.
Would it be possible to make the Python/CherryPy portion public? I'd
like to take a look at it and try it out.
Hopefully it's not hard to find, or I'll be reading Tess Ferrandez and
learning how to use windbg again. Ugh.
- Jeff
From merllab at microsoft.com Thu Apr 1 21:07:17 2010
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Thu, 1 Apr 2010 12:07:17 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID:
This is an automated email letting you know that sources
have recently been pushed out. You can download these newer
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/65179.
MODIFIED SOURCES
$/IronPython/IronPython_2_6/Src/AssemblyVersion.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/Properties/AssemblyInfo.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Scripting.Core/Properties/ExtensionAssemblyInfo.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Scripting.Core/Properties/AssemblyInfo.cs
$/IronPython/IronPython_2_6/Src/Hosts/SilverLight/Chiron/Properties/AssemblyInfo.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Scripting.Debugging/AssemblyInfo.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Scripting/Properties/AssemblyInfo.cs
From cgencer at gmail.com Thu Apr 1 23:44:02 2010
From: cgencer at gmail.com (Can Gencer)
Date: Thu, 1 Apr 2010 23:44:02 +0200
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
Message-ID:
On Thu, Apr 1, 2010 at 8:08 PM, Jeff Hardy wrote:
> On Thu, Apr 1, 2010 at 2:59 AM, Can Gencer wrote:
>> Hello,
>
> Hi Can,
> You are, to my knowledge, the first person besides me to use NWSGI for
> anything, so thank you!
>
>> Everything works after some tweaking done to CherryPy. I re-use the
>> application callable that is retrieved from the main script that is
>> compiled into CompiledCode . However the memory usage never seems to
>> go down, and goes up with every HTTP request, even if I force
>> GC.Collect() after every request.
>
> I haven't done any stress testing of NWSGI because my uses don't have
> any where near the traffic to need it :). It's quite possible that I'm
> holding to references to something (code objects maybe?) past there
> usefulness.
>
> Would it be possible to make the Python/CherryPy portion public? I'd
> like to take a look at it and try it out.
>
> Hopefully it's not hard to find, or I'll be reading Tess Ferrandez and
> learning how to use windbg again. Ugh.
>
> - Jeff
Hello,
The CherryPy code is very simple. I just have a "main.py" that gets
executed from the WSGI handler. All its doing is serving a static html
file that displays a lot of images which are stored under the
"/static" path. I am using CherryPy 3.1.2
---------------------------
import cherrypy
class HelloWorld:
def index(self):
return open('test.html').read()
index.exposed = True
import os.path
tutconf = os.path.join(os.path.dirname(__file__), 'app.conf')
current_dir = os.path.dirname(os.path.abspath(__file__))
appconfig = {'/static' :
{
'tools.staticdir.dir':
os.path.join(current_dir, 'static'),
'tools.staticdir.on' : True
}
}
cherrypy.config.update(tutconf)
application = cherrypy.tree.mount(HelloWorld(), "/", config=appconfig)
---------------------------
The app.conf looks like this (not sure if it's relevant, it was more
related to me testing a bunch of different stuff..)
---------------------------
[global]
tools.caching.on = False
tools.sessions.on = False
tools.sessions.timeout = 10
tools.encode.on: True
tools.encode.encoding: 'utf8'
log.screen = True
---------------------------
The html file I used for testing looks like this
---------------------------
...
---------------------------
To get CherryPy working, I edited two files process/plugins.py, changed
import signal as _signal
to
try:
import signal as _signal
except:
_signal = None
as signal package doesn't exist in IronPyhton.
Another change I made was related to threading, as without this change
CherryPy doesn't work thread safe and the local thread storage seems
to get corrupted..
in __init__.py, replaced
from threading import local as _local with from
cherrypy._cpthreadinglocal import local as _local
I don't know if the IronPython local module is buggy or this is
something related to CherryPy.. but this change seems to fix it.
It would be great if you can test this out with IIS and see if you get
the same results.. I don't know if IIS keeps one process in memory for
every request, but my web server is running as one process and reusing
the application callable
I will try Dino's suggestion about
ExceptionHelpers.DynamicStackFrames, is that a static class?
From cgencer at gmail.com Fri Apr 2 00:17:56 2010
From: cgencer at gmail.com (Can Gencer)
Date: Fri, 2 Apr 2010 00:17:56 +0200
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID:
On Thu, Apr 1, 2010 at 7:27 PM, Dino Viehland wrote:
> Can Gencer wrote:
>> I am trying to use CherryPy through IronPython. I am using a custom
>> web server written in C# and I am using the NWSGI handler available
>> here (http://nwsgi.codeplex.com/) with some modifications to work with
>> my custom web server instead of IIS.
>>
>> Everything works after some tweaking done to CherryPy. I re-use the
>> application callable that is retrieved from the main script that is
>> compiled into CompiledCode . However the memory usage never seems to
>> go down, and goes up with every HTTP request, even if I force
>> GC.Collect() after every request.
>>
>> The WSGI handler is invoking the delegate returned from the main
>> python script with some parameters that are standard in WSGI, such as
>> a start_response delegate ?Everytime a request is made, the handler
>> will invoke the application callable that is stored as a reference.
>>
>> CherryPy also has a built in web server that is using WSGI that can be
>> invoked with CPython. When testing that, there are no memory leaks.
>>
>> Any ideas on what the problem could be?
>
> The one issue that I know people have been running into is related to
> exception handling leaking memory. ?2.6.1 has some improvements to
> prevent this from happening but it still might happen. ?2.7 will have
> a permanent fix for this (which is available on CodePlex in as of this
> morning).
>
> To see if this is the problem you can check ExceptionHelpers.DynamicStackFrames
> and see if it's growing larger. ?You can set it to null if it is.
>
> If that's not it I can give some suggestions on how to debug it but
> usually involes windbg.
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
I tried this, ExceptionHelpers.DynamicStackFrames.Count seems to be
constant at 1.. I'm not very familiar with windbg but I can certainly
learn more about it.. What should I be looking for?
Thanks!
/Can
From jdhardy at gmail.com Fri Apr 2 00:23:29 2010
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 1 Apr 2010 16:23:29 -0600
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID:
On Thu, Apr 1, 2010 at 4:17 PM, Can Gencer wrote:
> On Thu, Apr 1, 2010 at 7:27 PM, Dino Viehland wrote:
> I tried this, ExceptionHelpers.DynamicStackFrames.Count seems to be
> constant at 1.. I'm not very familiar with windbg but I can certainly
> learn more about it.. What should I be looking for?
You could try running it under CLRProfiler:
http://www.microsoft.com/downloads/details.aspx?FamilyID=a362781c-3870-43be-8926-862b40aa0cd0&DisplayLang=en
http://msdn.microsoft.com/en-us/library/ms979205.aspx
With it you can see which objects stick around after a GC, what's
holding those objects, and where they're allocated. I'm not too
familiar with its use yet, but I plan on doing that tomorrow.
- Jeff
From dinov at microsoft.com Fri Apr 2 00:46:19 2010
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 1 Apr 2010 22:46:19 +0000
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
> On Thu, Apr 1, 2010 at 4:17 PM, Can Gencer wrote:
> > On Thu, Apr 1, 2010 at 7:27 PM, Dino Viehland wrote:
> > I tried this, ExceptionHelpers.DynamicStackFrames.Count seems to be
> > constant at 1.. I'm not very familiar with windbg but I can certainly
> > learn more about it.. What should I be looking for?
>
> You could try running it under CLRProfiler:
>
> http://www.microsoft.com/downloads/details.aspx?FamilyID=a362781c-3870-43be-
> 8926-862b40aa0cd0&DisplayLang=en
>
> http://msdn.microsoft.com/en-us/library/ms979205.aspx
>
> With it you can see which objects stick around after a GC, what's
> holding those objects, and where they're allocated. I'm not too
> familiar with its use yet, but I plan on doing that tomorrow.
Yeah CLRProfiler is a little more friendly :) I like windbg because it gives
reasonable way of tracking who's keeping what alive and I find it a little more
reliable than CLRProfiler. What I usually do is attach to the process after
letting it leak for a while and then:
.loadby sos mscorwks
Or
.loadbys sos clr
For CLR v2 and CLR v4 respectively. Then you can do:
!DumpHeap -stat
Run for a while, repeat that, and look at what types of objects are growing.
They should be at the end of the list because after running for a while they're
growing the most. Then you can do:
!DumpHeap -mt
Where is the address for the type that !DumpHeap -stat gave you.
Then you can start picking objects at random and do:
!GCRoot
And you see who's keeping it alive.
If the leaks big the places to look at pretty obvious. If it's leaking Python
objects defined in classes though you'll see those as "Unloaded Type".
From fuzzyman at voidspace.org.uk Fri Apr 2 00:49:28 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 01 Apr 2010 23:49:28 +0100
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <4BB522F8.9070600@voidspace.org.uk>
On 01/04/2010 23:46, Dino Viehland wrote:
>> On Thu, Apr 1, 2010 at 4:17 PM, Can Gencer wrote:
>>
>>> On Thu, Apr 1, 2010 at 7:27 PM, Dino Viehland wrote:
>>> I tried this, ExceptionHelpers.DynamicStackFrames.Count seems to be
>>> constant at 1.. I'm not very familiar with windbg but I can certainly
>>> learn more about it.. What should I be looking for?
>>>
>> You could try running it under CLRProfiler:
>>
>> http://www.microsoft.com/downloads/details.aspx?FamilyID=a362781c-3870-43be-
>> 8926-862b40aa0cd0&DisplayLang=en
>>
>> http://msdn.microsoft.com/en-us/library/ms979205.aspx
>>
>> With it you can see which objects stick around after a GC, what's
>> holding those objects, and where they're allocated. I'm not too
>> familiar with its use yet, but I plan on doing that tomorrow.
>>
> Yeah CLRProfiler is a little more friendly :) I like windbg because it gives
> reasonable way of tracking who's keeping what alive and I find it a little more
> reliable than CLRProfiler. What I usually do is attach to the process after
> letting it leak for a while and then:
>
>
Kamil Dworakowski wrote an interesting blog entry on tracing memory
leaks in IronPython apps with windbg:
http://blog.kamil.dworakowski.name/2008/02/debugging-memory-problems-in-ironpython.html
All the best,
Michael Foord
> .loadby sos mscorwks
> Or
> .loadbys sos clr
>
> For CLR v2 and CLR v4 respectively. Then you can do:
>
> !DumpHeap -stat
>
> Run for a while, repeat that, and look at what types of objects are growing.
> They should be at the end of the list because after running for a while they're
> growing the most. Then you can do:
>
> !DumpHeap -mt
>
> Where is the address for the type that !DumpHeap -stat gave you.
>
> Then you can start picking objects at random and do:
>
> !GCRoot
>
> And you see who's keeping it alive.
>
> If the leaks big the places to look at pretty obvious. If it's leaking Python
> objects defined in classes though you'll see those as "Unloaded Type".
>
>
> _______________________________________________
> 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
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
From cgencer at gmail.com Fri Apr 2 17:05:04 2010
From: cgencer at gmail.com (Can Gencer)
Date: Fri, 2 Apr 2010 17:05:04 +0200
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To: <4BB522F8.9070600@voidspace.org.uk>
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
<4BB522F8.9070600@voidspace.org.uk>
Message-ID:
On Fri, Apr 2, 2010 at 12:49 AM, Michael Foord
wrote:
> On 01/04/2010 23:46, Dino Viehland wrote:
>>>
>>> On Thu, Apr 1, 2010 at 4:17 PM, Can Gencer ?wrote:
>>>
>>>>
>>>> On Thu, Apr 1, 2010 at 7:27 PM, Dino Viehland
>>>> ?wrote:
>>>> I tried this, ExceptionHelpers.DynamicStackFrames.Count seems to be
>>>> constant at 1.. I'm not very familiar with windbg but I can certainly
>>>> learn more about it.. What should I be looking for?
>>>>
>>>
>>> You could try running it under CLRProfiler:
>>>
>>>
>>> http://www.microsoft.com/downloads/details.aspx?FamilyID=a362781c-3870-43be-
>>> 8926-862b40aa0cd0&DisplayLang=en
>>>
>>> http://msdn.microsoft.com/en-us/library/ms979205.aspx
>>>
>>> With it you can see which objects stick around after a GC, what's
>>> holding those objects, and where they're allocated. I'm not too
>>> familiar with its use yet, but I plan on doing that tomorrow.
>>>
>>
>> Yeah CLRProfiler is a little more friendly :) ?I like windbg because it
>> gives
>> reasonable way of tracking who's keeping what alive and I find it a little
>> more
>> reliable than CLRProfiler. ?What I usually do is attach to the process
>> after
>> letting it leak for a while and then:
>>
>>
>
> Kamil Dworakowski wrote an interesting blog entry on tracing memory leaks in
> IronPython apps with windbg:
>
> http://blog.kamil.dworakowski.name/2008/02/debugging-memory-problems-in-ironpython.html
>
> All the best,
>
> Michael Foord
>
>> .loadby sos mscorwks
>> ? ? ? ?Or
>> .loadbys sos clr
>>
>> For CLR v2 and CLR v4 respectively. ?Then you can do:
>>
>> !DumpHeap -stat
>>
>> Run for a while, repeat that, and look at what types of objects are
>> growing.
>> They should be at the end of the list because after running for a while
>> they're
>> growing the most. ?Then you can do:
>>
>> !DumpHeap -mt
>>
>> Where ?is the address for the type that !DumpHeap -stat gave
>> you.
>>
>> Then you can start picking objects at random and do:
>>
>> !GCRoot
>>
>> And you see who's keeping it alive.
>>
>> If the leaks big the places to look at pretty obvious. ?If it's leaking
>> Python
>> objects defined in classes though you'll see those as "Unloaded Type".
>>
>>
I did some more digging around this, I tried using the wsgi.py found
in FePy instead (and modifying it to fit with my webserver) and the
results seem to be better, although not perfect.
There seems to be a whole bunch of objects that are referenced from this root:
ESP:550f3e8:Root:015c0150(Microsoft.Scripting.Ast.Block2)->
015c00fc(Microsoft.Scripting.Ast.ScopeN)->
015c00ec(System.Runtime.CompilerServices.TrueReadOnlyCollection`1[[Microsoft.Scripting.Ast.Expression,
Microsoft.Scripting.Core]])->
015c002c(System.Object[])->
What is this exactly?
Also I have a question about ScriptScopes. Do they get garbage
collected when a ScriptScope goes out of scope?
From merllab at microsoft.com Fri Apr 2 17:53:30 2010
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Fri, 2 Apr 2010 08:53:30 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID:
This is an automated email letting you know that sources
have recently been pushed out. You can download these newer
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/65202.
MODIFIED SOURCES
$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/AstMethods.cs
$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/CallExpression.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/Operations/PythonOps.cs
CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 1709228
Date: 4/1/2010 11:51:06 AM
Fixes the Pyc Unicode regression: Call a function to get the Unicode helper object instead of burning it in as a constant.
(Shelveset: FixUnicodePycRegression;REDMOND\dinov | SNAP CheckinId: 10620)
From dinov at microsoft.com Fri Apr 2 18:30:35 2010
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 2 Apr 2010 16:30:35 +0000
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
<4BB522F8.9070600@voidspace.org.uk>
Message-ID: <1A472770E042064698CB5ADC83A12ACD394ECD9E@TK5EX14MBXC118.redmond.corp.microsoft.com>
Can Gencer wrote:
>
> I did some more digging around this, I tried using the wsgi.py found
> in FePy instead (and modifying it to fit with my webserver) and the
> results seem to be better, although not perfect.
>
> There seems to be a whole bunch of objects that are referenced from this root:
>
> ESP:550f3e8:Root:015c0150(Microsoft.Scripting.Ast.Block2)->
> 015c00fc(Microsoft.Scripting.Ast.ScopeN)->
> 015c00ec(System.Runtime.CompilerServices.TrueReadOnlyCollection`1[[Microsoft.S
> cripting.Ast.Expression,
> Microsoft.Scripting.Core]])->
> 015c002c(System.Object[])->
>
> What is this exactly?
Block2/ScopeN are DLR expression trees. They hold onto more expression trees
or variables and more expression trees. Can you do !DumpArray on 15c002c?
I'm curious how big the array is - is it that the array's holding onto the objects
or something in the array? I would assume it's something in the array.
>
> Also I have a question about ScriptScopes. Do they get garbage
> collected when a ScriptScope goes out of scope?
More or less the answer is yes. We can compile code in an optimized form which
is uncollectible but we should only do this for .py files which are getting
compiled when executing from the command line. Even then the ScriptScope will
get collected but a bunch of other info won't.
From jdhardy at gmail.com Fri Apr 2 21:49:18 2010
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 2 Apr 2010 13:49:18 -0600
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID:
I'm seeing a lot of objects with !gcroots that start with
DOMAIN(005F5F48):HANDLE(Strong):161100:Root:02913dac(System.Threading.Thread)->
0b93e034(System.Object[][])->
0b93e048(System.Object[])->
223edd34(System.Collections.Generic.List`1[[Microsoft.Scripting.Runtime.DynamicStackFrame,
Microsoft.Dynamic]])->
223edd6c(System.Object[])->
223edd4c(IronPython.Runtime.PythonDynamicStackFrame)->
09441a48(IronPython.Runtime.FunctionCode)->
...
So it looks like it might be related to dynamic stack frames --
something that is in thread local storage and not getting cleaned up.
- Jeff
From dinov at microsoft.com Fri Apr 2 22:52:42 2010
From: dinov at microsoft.com (Dino Viehland)
Date: Fri, 2 Apr 2010 20:52:42 +0000
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
Jeff wrote:
> I'm seeing a lot of objects with !gcroots that start with
>
> DOMAIN(005F5F48):HANDLE(Strong):161100:Root:02913dac(System.Threading.Thread)-
> >
> 0b93e034(System.Object[][])->
> 0b93e048(System.Object[])->
> 223edd34(System.Collections.Generic.List`1[[Microsoft.Scripting.Runtime.Dynami
> cStackFrame,
> Microsoft.Dynamic]])->
> 223edd6c(System.Object[])->
> 223edd4c(IronPython.Runtime.PythonDynamicStackFrame)->
> 09441a48(IronPython.Runtime.FunctionCode)->
> ...
>
> So it looks like it might be related to dynamic stack frames --
> something that is in thread local storage and not getting cleaned up.
Is this 2.6 or 2.6.1RC? I wonder if this could be the finalizer thread.
!do on the thread object should give you the managed thread ID which can be
associated with the values in !threads.
Anyway this is definitely the exception leak - which is now fixed for 2.7. If
This is happening on the finalizer thread then maybe there's somewhere else we
need to clear this data for pre-2.7.
From jdhardy at gmail.com Sat Apr 3 00:29:00 2010
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 2 Apr 2010 16:29:00 -0600
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID:
On Fri, Apr 2, 2010 at 2:52 PM, Dino Viehland wrote:
> Is this 2.6 or 2.6.1RC? ?I wonder if this could be the finalizer thread.
> !do on the thread object should give you the managed thread ID which can be
> associated with the values in !threads.
This is 2.6.0. It looks like its one of the server's worker threads
(I'm just using the built-in VS webserver), at least from a random
sample of objects.
Are the fixes in 2.6.1 RC1?
>
> Anyway this is definitely the exception leak - which is now fixed for 2.7. ?If
> This is happening on the finalizer thread then maybe there's somewhere else we
> need to clear this data for pre-2.7.
I hate to ask the ETA for 2.7 is - fall, probably?
- Jeff
From jdhardy at gmail.com Sat Apr 3 00:36:03 2010
From: jdhardy at gmail.com (Jeff Hardy)
Date: Fri, 2 Apr 2010 16:36:03 -0600
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID:
On Fri, Apr 2, 2010 at 4:29 PM, Jeff Hardy wrote:
> On Fri, Apr 2, 2010 at 2:52 PM, Dino Viehland wrote:
>> Is this 2.6 or 2.6.1RC? ?I wonder if this could be the finalizer thread.
>> !do on the thread object should give you the managed thread ID which can be
>> associated with the values in !threads.
>
> This is 2.6.0.
And it looks like 2.6.1 RC1 has basically the same behaviour.
- Jeff
From dinov at microsoft.com Sat Apr 3 04:06:07 2010
From: dinov at microsoft.com (Dino Viehland)
Date: Sat, 3 Apr 2010 02:06:07 +0000
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD394EF8DB@TK5EX14MBXC118.redmond.corp.microsoft.com>
Jeff wrote:
> I hate to ask the ETA for 2.7 is - fall, probably?
End of year is what we've been saying.
From dinov at microsoft.com Sat Apr 3 04:06:51 2010
From: dinov at microsoft.com (Dino Viehland)
Date: Sat, 3 Apr 2010 02:06:51 +0000
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD394EF8FE@TK5EX14MBXC118.redmond.corp.microsoft.com>
Jeff wrote:
> This is 2.6.0. It looks like its one of the server's worker threads
> (I'm just using the built-in VS webserver), at least from a random
> sample of objects.
>
> Are the fixes in 2.6.1 RC1?
Yes there are some fixes in 2.6.1 RC1 but obviously they're not working.
Can you clear the exception data from the server at all?
From cgencer at gmail.com Sat Apr 3 17:15:12 2010
From: cgencer at gmail.com (Can Gencer)
Date: Sat, 3 Apr 2010 17:15:12 +0200
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID:
I do not have the DynamicStackFrame problem, though I do not have
Frames enabled.
I 've managed to solve all the memory leak issues now (hopefully), the
last one was caused by the session handler in CherryPy. The cleanup
thread was not being started due to some reason. It seems that you
have to call the cherrypy.session object at least once to start up the
cleanup thread.
I use the wsgi.py found in FePy like this (if anyone is interested in
trying it out..)
public void ProcessRequest(HttpContext context)
{
var func = GetWsgiFunction();
func.__code__.Target.DynamicInvoke(func, context,
GetApplicationCallable(_engine), context.ApplicationPath);
}
private PythonFunction GetWsgiFunction()
{
if (_wsgiFunction = null)
{
ScriptScope scope = _engine.CreateScope();
_engine.CreateScriptSourceFromString("import
wsgi").Execute(scope);
_wsgiFunction =
scope.GetVariable("wsgi").Get__dict__()["run_application"]
as PythonFunction;
}
return _wsgiMethod;
}
GetApplicationCallable returns the application callable that is
created by CherryPy, that you get like this:
import cherrypy
application = cherrypy.tree.mount(root, "/")
On Fri, Apr 2, 2010 at 10:52 PM, Dino Viehland wrote:
>
>
> Jeff wrote:
>> I'm seeing a lot of objects with !gcroots that start with
>>
>> DOMAIN(005F5F48):HANDLE(Strong):161100:Root:02913dac(System.Threading.Thread)-
>> >
>> 0b93e034(System.Object[][])->
>> 0b93e048(System.Object[])->
>> 223edd34(System.Collections.Generic.List`1[[Microsoft.Scripting.Runtime.Dynami
>> cStackFrame,
>> Microsoft.Dynamic]])->
>> 223edd6c(System.Object[])->
>> 223edd4c(IronPython.Runtime.PythonDynamicStackFrame)->
>> 09441a48(IronPython.Runtime.FunctionCode)->
>> ...
>>
>> So it looks like it might be related to dynamic stack frames --
>> something that is in thread local storage and not getting cleaned up.
>
> Is this 2.6 or 2.6.1RC? ?I wonder if this could be the finalizer thread.
> !do on the thread object should give you the managed thread ID which can be
> associated with the values in !threads.
>
> Anyway this is definitely the exception leak - which is now fixed for 2.7. ?If
> This is happening on the finalizer thread then maybe there's somewhere else we
> need to clear this data for pre-2.7.
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
From michael at voidspace.org.uk Sun Apr 4 22:24:39 2010
From: michael at voidspace.org.uk (Michael Foord)
Date: Sun, 04 Apr 2010 21:24:39 +0100
Subject: [IronPython] winforms and avalon samples
Message-ID: <4BB8F587.30708@voidspace.org.uk>
Hello guys,
It seems like the tutorial installed with IronPython 2.6 refer to the
winforms and avalon modules that used to be shipped with IronPython, but
aren't any more?
> The Tutorial installed as part of 2.6 still refers to winforms ( file://localhost/C:/Program%20Files/IronPython%202.6/Tutorial/Tutorial.htm#T2.2 >).
> I don't see it in the 2.6 distribution, nor is "avalon", which also appears
> in the Tutorial. I can entirely understand that you abandoned them; I just
> want to get my story straight, before I turn students loose on the installed
> Tutorial.
>
All the best,
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
From merllab at microsoft.com Mon Apr 5 17:53:30 2010
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Mon, 5 Apr 2010 08:53:30 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <58d62421-56e2-472a-813b-cd7033eff4fd@tk5-exsmh-c101.redmond.corp.microsoft.com>
This is an automated email letting you know that sources
have recently been pushed out. You can download these newer
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/65283.
ADDED SOURCES
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/repl_formatter.rb
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/repl_formatter.py
MODIFIED SOURCES
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/repl_formatter.rb
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/repl_formatter.py
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/init.rb
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/DynamicScriptTags.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/XamlScriptTags.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ComInvokeBinder.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ComFallbackMetaObject.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ComBinderHelpers.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ComMetaObject.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ConvertibleArgBuilder.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ConversionArgBuilder.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/BoolArgBuilder.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/BrowserVirtualFilesystem.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/DynamicEngine.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/agdlr.css
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Repl.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/HttpSocket.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/App.config
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/Microsoft.Scripting.Silverlight.csproj
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/VariantArgBuilder.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/StringArgBuilder.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/UnknownArgBuilder.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/DispatchArgBuilder.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/DateTimeArgBuilder.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/ComInterop/ErrorArgBuilder.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/LanguageInfo.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/XapBuilder.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/DynamicApplication.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Microsoft.Scripting.Silverlight/ExtensionTypes.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/Chiron.cs
$/IronPython/IronPython_Main/Src/Hosts/SilverLight/Chiron/HttpServer.cs
$/IronPython/IronPython_Main/Src/IronPython/Runtime/PythonOptions.cs
$/IronPython/IronPython_Main/Src/IronPython.Modules/IronPython.Modules.csproj
$/IronPython/IronPython_Main/Src/IronPython/Compiler/Ast/FunctionDefinition.cs
$/IronPython/IronPython_Main/Src/IronPython/IronPython.csproj
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/BranchLabel.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/ControlFlowInstructions.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/InstructionList.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/TypeOperations.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/InstructionFactory.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Instructions/LocalAccess.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/Interpreter.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/InterpretedFrame.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LocalVariables.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightLambdaClosureVisitor.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightCompiler.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LightDelegateCreator.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Interpreter/LoopCompiler.cs
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Dynamic/Utils/HashSet.cs
CHECKIN COMMENTS
--------------------------------------------------------------------------------
Changeset Id: 1712859
Date: 4/5/2010 1:36:21 AM
Silverlight fixes from PyCon and MIX
====================================
Touches IronPython/IronRuby, Microsoft.Scripting.Silverlight, and Chiron.
-------------------
IronPython/IronRuby
-------------------
- IronPython.csproj was mistakenly looking for System.Core when referencing
System.Numerics
- IronPython.Modules.csproj and Ruby.csproj weren't using the $(SignedSym) in Silverlight
builds, and IronPython.Modules.csproj needed a reference to System.Numerics for Silverlight 4
builds
-------------------------------
Microsoft.Scripting.Silverlight
-------------------------------
Zip-file script-tags
++++++++++++++++++++
Script-tags now support zip-file sources, for packaging assemblies, any
other binary data, or large script libraries. The zip-file name is then
recognized as a top-level directory on the virtual file-system, so
import/require will load files out of there, as well directly opening
the file.
NOTE: When using zip-file script-tags AND running on localhost
(non-internet location) AND using the binaries hosted online
(gestalt.ironpython.net, or any other internet location), the downloader
fails over to a XmlHttpRequest downloader, which has limitations with
handling binary data in Internet Explorer. While I've tried to work
around them, performance of loading a 100k+ zip file in IE comes to a
crawl. Since this scenario is only apparent during development, the
work-around is to download the DLR+Language binaries and depend on them
locally. This is not an issue when both the application and the DLR
assemblies are hosted on an internet location (foo.com and
gestalt.ironpython.net, for example), as then the Silverlight downloader
will be used, which handles binary data just fine. Let me reiterate
that this is only an issue for Internet Explorer.
Python DOM event handling
+++++++++++++++++++++++++
DOM event handling in Python is also improved by a slight change in DOM
event handling syntax:
def say_hello(*args):
print "Hello!"
document.button.events.onclick += say_hello
Every HtmlObject has an "events" property, which allows you to hook DOM
events with the += syntax.
Deferred XAML loading
+++++++++++++++++++++
XAML script-tags now support the "defer" attribute, still creating a
Silverlight control but not loading the XAML:
This allows the script to control when the Silverlight loading animation
stops.
REPL formatting per language
++++++++++++++++++++++++++++
Now the REPL has custom formatting per language; prompt color, result
inspection, etc. For example, Python's prompt is now yellow, and no
longer shows the Ruby "=>" for non "None" return values.
REPL demo mode
++++++++++++++
If demoing the build-in REPL on a projector for a decent-sized room, you
can add the "demo" ID to the body tag to double the size and fonts of the
console window.
Other fixes
+++++++++++
- REPL style fixes across IE, FF, Chrome, Safari
- Fix OOB support
- Stack overflow fix for missing DOM properties in Ruby
- Fix Safari property setting in Ruby
- FIX DLRConsole when running against unsigned binaries
- FIX both Ruby and Python "photos" sample
------
Chiron
------
Previously Chiron used the "externalUrlPrefix" setting to decide
whether or not the DLR assemblies should be put in the XAP, or
Silverlight 3's transparent platform extensions (TPEs) should be
used instead. However, only the DLR assemblies are ever used as
TPEs; the languages are either in the XAP as assemblies or downloaded
if used. So these two ideas are now split appart, mainly to allow
generating a XAP file that will work with Moonlight 2.
- 'useExtensions' toggle tells Chiron to generate a XAP file
which loads the DLR via Silverlight's transparent platform
extensions (if set to true), or just put the DLR assemblies
in the XAP (if set to false).
- 'detectLanguages' toggle to tell Chiron to detect what language
the app uses by just looking through the folder which will be zipped.
If true, it will detect the languages and make sure the language
assemblies are avaliable to the XAP file (either as DLLs or SLVXs,
dependent on the useExtensions value). Otherwise, it does no
language detection (in this case Microsoft.Scripting.Silverlight
is responcible for doing language detection and downloading of language
assemblies).
Also, to better support the downloading of the language binaries, urlPrefix
has been "undepricated", and externalUrlPrefix has been removed. Now *any file*
(not just DLLs or PDBs) in the localAssemblyPath will be served from the
urlPrefix URL.
Other fixes/tweaks
++++++++++++++++++
- By default it generates a XAP that can be installed OOB
- Now works as an internet-facing web-server, rather than just listening
on localhost.
- Allows files to be cached from Chiron (use to send the no-cache header)
Note: Though the gestalt-style application model does not require Chiron to be
used by application developers, Chiron is still a very useful tool for
language developers to test Silverlight applications under their language,
since it automatically picks up new language/DLR binaries. Also, using Chiron
and generating a unique XAP per application is the only way to write OOB-enabled
applications. So Chiron will continue to be supported as a web-server and
XAP generator for dynamic language applications.
--------------
Infrastructure
--------------
- Silverlight build drops now contain dlr.js and dlr.xap
- Now support building against Silverlight 4 RC
(Shelveset: slpyconmix;REDMOND\jimmysch | SNAP CheckinId: 10647)
--------------------------------------------------------------------------------
Changeset Id: 1712319
Date: 4/3/2010 6:01:11 PM
Supports shadowing of variables. We now undefined variables when they go out of scope and keep track of variables being redfined below the current scope. When a variable gets boxed to a closure we now only box the relevant ranges. Because of this LocalVariables is a more expensive data structure so I?ve made it so we don?t hold onto it after compilation ? instead we flow in information such as closure size where we need it. For closued over parameters we now we emit a parameter initialization instruction which by default does nothing. When we box the parameter we change it into an instruction which creates a strong box around the initial parameter value. This also removes our ?BoxLocals? phase when entering a method which may have been boxing too much.
The loop compiler also gets updated ? it just needs to track variables which are local to the loop.
Adds the TypeAs instruction which was missing.
Fixes a bug w/ Goto expression. When the goto has a value but that value is void we?re not accurately tracking the stack size.
(Shelveset: InterpreterBugsFinal2;REDMOND\dinov | SNAP CheckinId: 10644)
--------------------------------------------------------------------------------
Changeset Id: 1712859
Date: 4/5/2010 1:36:21 AM
Silverlight fixes from PyCon and MIX
====================================
Touches IronPython/IronRuby, Microsoft.Scripting.Silverlight, and Chiron.
-------------------
IronPython/IronRuby
-------------------
- IronPython.csproj was mistakenly looking for System.Core when referencing
System.Numerics
- IronPython.Modules.csproj and Ruby.csproj weren't using the $(SignedSym) in Silverlight
builds, and IronPython.Modules.csproj needed a reference to System.Numerics for Silverlight 4
builds
-------------------------------
Microsoft.Scripting.Silverlight
-------------------------------
Zip-file script-tags
++++++++++++++++++++
Script-tags now support zip-file sources, for packaging assemblies, any
other binary data, or large script libraries. The zip-file name is then
recognized as a top-level directory on the virtual file-system, so
import/require will load files out of there, as well directly opening
the file.
NOTE: When using zip-file script-tags AND running on localhost
(non-internet location) AND using the binaries hosted online
(gestalt.ironpython.net, or any other internet location), the downloader
fails over to a XmlHttpRequest downloader, which has limitations with
handling binary data in Internet Explorer. While I've tried to work
around them, performance of loading a 100k+ zip file in IE comes to a
crawl. Since this scenario is only apparent during development, the
work-around is to download the DLR+Language binaries and depend on them
locally. This is not an issue when both the application and the DLR
assemblies are hosted on an internet location (foo.com and
gestalt.ironpython.net, for example), as then the Silverlight downloader
will be used, which handles binary data just fine. Let me reiterate
that this is only an issue for Internet Explorer.
Python DOM event handling
+++++++++++++++++++++++++
DOM event handling in Python is also improved by a slight change in DOM
event handling syntax:
def say_hello(*args):
print "Hello!"
document.button.events.onclick += say_hello
Every HtmlObject has an "events" property, which allows you to hook DOM
events with the += syntax.
Deferred XAML loading
+++++++++++++++++++++
XAML script-tags now support the "defer" attribute, still creating a
Silverlight control but not loading the XAML:
This allows the script to control when the Silverlight loading animation
stops.
REPL formatting per language
++++++++++++++++++++++++++++
Now the REPL has custom formatting per language; prompt color, result
inspection, etc. For example, Python's prompt is now yellow, and no
longer shows the Ruby "=>" for non "None" return values.
REPL demo mode
++++++++++++++
If demoing the build-in REPL on a projector for a decent-sized room, you
can add the "demo" ID to the body tag to double the size and fonts of the
console window.
Other fixes
+++++++++++
- REPL style fixes across IE, FF, Chrome, Safari
- Fix OOB support
- Stack overflow fix for missing DOM properties in Ruby
- Fix Safari property setting in Ruby
- FIX DLRConsole when running against unsigned binaries
- FIX both Ruby and Python "photos" sample
------
Chiron
------
Previously Chiron used the "externalUrlPrefix" setting to decide
whether or not the DLR assemblies should be put in the XAP, or
Silverlight 3's transparent platform extensions (TPEs) should be
used instead. However, only the DLR assemblies are ever used as
TPEs; the languages are either in the XAP as assemblies or downloaded
if used. So these two ideas are now split appart, mainly to allow
generating a XAP file that will work with Moonlight 2.
- 'useExtensions' toggle tells Chiron to generate a XAP file
which loads the DLR via Silverlight's transparent platform
extensions (if set to true), or just put the DLR assemblies
in the XAP (if set to false).
- 'detectLanguages' toggle to tell Chiron to detect what language
the app uses by just looking through the folder which will be zipped.
If true, it will detect the languages and make sure the language
assemblies are avaliable to the XAP file (either as DLLs or SLVXs,
dependent on the useExtensions value). Otherwise, it does no
language detection (in this case Microsoft.Scripting.Silverlight
is responcible for doing language detection and downloading of language
assemblies).
Also, to better support the downloading of the language binaries, urlPrefix
has been "undepricated", and externalUrlPrefix has been removed. Now *any file*
(not just DLLs or PDBs) in the localAssemblyPath will be served from the
urlPrefix URL.
Other fixes/tweaks
++++++++++++++++++
- By default it generates a XAP that can be installed OOB
- Now works as an internet-facing web-server, rather than just listening
on localhost.
- Allows files to be cached from Chiron (use to send the no-cache header)
Note: Though the gestalt-style application model does not require Chiron to be
used by application developers, Chiron is still a very useful tool for
language developers to test Silverlight applications under their language,
since it automatically picks up new language/DLR binaries. Also, using Chiron
and generating a unique XAP per application is the only way to write OOB-enabled
applications. So Chiron will continue to be supported as a web-server and
XAP generator for dynamic language applications.
--------------
Infrastructure
--------------
- Silverlight build drops now contain dlr.js and dlr.xap
- Now support building against Silverlight 4 RC
(Shelveset: slpyconmix;REDMOND\jimmysch | SNAP CheckinId: 10647)
From merllab at microsoft.com Mon Apr 5 21:07:32 2010
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Mon, 5 Apr 2010 12:07:32 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID:
This is an automated email letting you know that sources
have recently been pushed out. You can download these newer
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/65287.
MODIFIED SOURCES
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/ComFallbackMetaObject.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/ConvertibleArgBuilder.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/ConversionArgBuilder.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/ComBinderHelpers.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/ComMetaObject.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/ComInvokeBinder.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/BoolArgBuilder.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/StringArgBuilder.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/DateTimeArgBuilder.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/ErrorArgBuilder.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/DispatchArgBuilder.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/UnknownArgBuilder.cs
$/IronPython/IronPython_2_6/Src/Runtime/Microsoft.Dynamic/ComInterop/VariantArgBuilder.cs
From drken567 at gmail.com Mon Apr 5 21:25:54 2010
From: drken567 at gmail.com (Ken MacDonald)
Date: Mon, 5 Apr 2010 15:25:54 -0400
Subject: [IronPython] WPF / ipy minimize weirdness?
Message-ID:
Hi,
I have a WPF app and I'm trying to mess with WindowState. I have two
windows, a modal selection dialog, and a main window. If I bring up the
selection dialog with the main window in background, and minimize the
selection dialog, it leaves the main window visible but you can't interact
with it. So far, normal.
If I make a selection, the select dialog closes leaving the main window, and
I can minimize the main window using the standard windows controls, and
restore it from the taskbar. OK so far.
However, I want to get it working like this: if I minimize the selection
dialog, I'd like to minimize the main window also. So, I added an event
listener on StateChanged, something like:
def state_changed(...):
if self._w.WindowState == WindowState.Minimized:
main_window.WindowState = WindowState.Minimized
This captures the minimize event, both the selection dialog and main window
minimize, BUT now I can't right-or-left-click on the minimized app to get it
to restore, and have to kill the app using task manager. Also, it appears
that instead of having two windows represented on the taskbar, only the main
window is left - even though I should still have both the select dialog and
the main window minimized.
Is there some magic state I need to set in the main window to be able to
have it restore again? Why should it make a difference whether the minimize
is done by the main window 'min' button, or by setting its WindowState?
Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Jimmy.Schementi at microsoft.com Mon Apr 5 22:08:54 2010
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Mon, 5 Apr 2010 20:08:54 +0000
Subject: [IronPython] winforms and avalon samples
In-Reply-To: <4BB8F587.30708@voidspace.org.uk>
References: <4BB8F587.30708@voidspace.org.uk>
Message-ID: <1B42307CD4AADD438CDDA2FE1121CC921731C7C4@TK5EX14MBXC136.redmond.corp.microsoft.com>
avalon.py and winforms.py are still in the "Tutorial" directory of the IronPython binary zip, as well as in the installer ...
-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Sunday, April 04, 2010 1:25 PM
To: Discussion of IronPython
Cc: Cameron Laird
Subject: [IronPython] winforms and avalon samples
Hello guys,
It seems like the tutorial installed with IronPython 2.6 refer to the
winforms and avalon modules that used to be shipped with IronPython, but
aren't any more?
> The Tutorial installed as part of 2.6 still refers to winforms ( file://localhost/C:/Program%20Files/IronPython%202.6/Tutorial/Tutorial.htm#T2.2 >).
> I don't see it in the 2.6 distribution, nor is "avalon", which also appears
> in the Tutorial. I can entirely understand that you abandoned them; I just
> want to get my story straight, before I turn students loose on the installed
> Tutorial.
>
All the best,
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
From fuzzyman at voidspace.org.uk Mon Apr 5 22:10:04 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Mon, 05 Apr 2010 21:10:04 +0100
Subject: [IronPython] winforms and avalon samples
In-Reply-To: <1B42307CD4AADD438CDDA2FE1121CC921731C7C4@TK5EX14MBXC136.redmond.corp.microsoft.com>
References: <4BB8F587.30708@voidspace.org.uk>
<1B42307CD4AADD438CDDA2FE1121CC921731C7C4@TK5EX14MBXC136.redmond.corp.microsoft.com>
Message-ID: <4BBA439C.5030702@voidspace.org.uk>
On 05/04/2010 21:08, Jimmy Schementi wrote:
> avalon.py and winforms.py are still in the "Tutorial" directory of the IronPython binary zip, as well as in the installer ...
>
Thanks Jimmy.
Michael
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Sunday, April 04, 2010 1:25 PM
> To: Discussion of IronPython
> Cc: Cameron Laird
> Subject: [IronPython] winforms and avalon samples
>
> Hello guys,
>
> It seems like the tutorial installed with IronPython 2.6 refer to the
> winforms and avalon modules that used to be shipped with IronPython, but
> aren't any more?
>
>
>> The Tutorial installed as part of 2.6 still refers to winforms (> file://localhost/C:/Program%20Files/IronPython%202.6/Tutorial/Tutorial.htm#T2.2>).
>> I don't see it in the 2.6 distribution, nor is "avalon", which also appears
>> in the Tutorial. I can entirely understand that you abandoned them; I just
>> want to get my story straight, before I turn students loose on the installed
>> Tutorial.
>>
>>
> All the best,
>
> Michael
>
>
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (?BOGUS AGREEMENTS?) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
From Jimmy.Schementi at microsoft.com Tue Apr 6 03:21:31 2010
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 6 Apr 2010 01:21:31 +0000
Subject: [IronPython] Python questions on DLR forums
Message-ID: <1B42307CD4AADD438CDDA2FE1121CC921731D2D0@TK5EX14MBXC136.redmond.corp.microsoft.com>
Ironpython, os.system does not work correctly but does in regular Python
http://social.msdn.microsoft.com/Forums/en-US/dlr/thread/e43322ce-a0b8-483e-a69d-416e73381666
IronPython using WCF client w config
http://social.msdn.microsoft.com/Forums/en-US/dlr/thread/0c08afaa-252f-442e-b8d2-e1cdb9e0d522
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Jimmy.Schementi at microsoft.com Tue Apr 6 08:20:02 2010
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 6 Apr 2010 06:20:02 +0000
Subject: [IronPython] IronPython for asp.net and codefiles
In-Reply-To: <8cd017b81003241309x7c035087kd7f3c9d2cd4e7d94@mail.gmail.com>
References:
<8cd017b81003210149m19020d65h2d2ec108cb9c3e1c@mail.gmail.com>
<1B42307CD4AADD438CDDA2FE1121CC921015067C@TK5EX14MBXC134.redmond.corp.microsoft.com>
<8cd017b81003241309x7c035087kd7f3c9d2cd4e7d94@mail.gmail.com>
Message-ID: <1B42307CD4AADD438CDDA2FE1121CC921731D9A1@TK5EX14MBXC136.redmond.corp.microsoft.com>
No, currently the caching isn't customizable, but the caching is just the compiled code; the output of the HTML page is not cached at all by the DLR integration, so authentication should work just fine.
From: Dody Gunawinata [mailto:empirebuilder at gmail.com]
Sent: Wednesday, March 24, 2010 1:09 PM
To: Jimmy Schementi
Cc: Discussion of IronPython; pablodalma93 at hotmail.com
Subject: Re: [IronPython] IronPython for asp.net and codefiles
Is there any way to control the when IP for ASP.Net does the caching?
I have been using VirtualPathProvider to serve IP ascx/aspx code on demand but I have to disable the caching completely via public override CacheDependency GetCacheDependency because I need to server different codes depending on authentication.
On Sun, Mar 21, 2010 at 10:33 PM, Jimmy Schementi > wrote:
Pablo, what is the reason you are looking into obfuscation? Is it because you're concerned that people could make requests for your *.aspx.py files and see the Python source? By default any request for a *.aspx.py file should fail because that file extensions is not in the MIME type map on IIS. That should be enough for any obfuscation you need.
Note that C#/VB "obfuscation" through compiling to DLLs isn't really obfuscation either; if you had access to the DLL you could get all the source code. However, IIS by default refuses access to the "bin" directory. So, the methods of hiding source code are essentially the same between static and dynamic languages; refuse access to the actual source files.
Quick note on compiled modules: Microsoft.Web.Scripting.dll caches compiled Python modules, so on the first visit to an ASPX page that uses IronPython it compiles the code-behind .aspx.py file in memory, and subsequent visits reuses the compiled file. The Python file is only re-compiled if it's changed between requests.
~js
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dody Gunawinata
Sent: Sunday, March 21, 2010 1:49 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython for asp.net and codefiles
If you want to hide your logic from the source, move as much of the functionality to a dll, whether it is a static or ironpython dll. I don't think IronPython for ASP.Net supports compilable asp.net.
On Sat, Mar 6, 2010 at 4:52 PM, Pablo Dalmazzo > wrote:
Hi there,
now I got to work the dlls and I did a small app. which turns my asp.net .py codefile into 2 pieces, a .py codefile which makes only functions calls to a dll with the actual logic code. But I was wondering why IronPython for asp.net was designed without having in mind to allow the .aspx files to be tied with dlls for the sourcecode, for allowing obfuscation just like it's possible to make in VB.NET or C#. Or may be it just wasnt easy at all to do that for IronPython? Is the technical explanation too complicated or may I know about it? Is there information about this somewhere?
Greetins, Pablo
________________________________
Tu Hotmail guarda el borrador que est?s escribiendo para que no pierdas tu mensaje. Conoc? c?mo
_______________________________________________
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 mustaq2001 at gmail.com Tue Apr 6 08:37:27 2010
From: mustaq2001 at gmail.com (mohammad mustaq)
Date: Tue, 6 Apr 2010 12:07:27 +0530
Subject: [IronPython] IronPython.Runtime.Types.PythonType Is not marked as
Serializable Exception
Message-ID:
Hi Dino,
If have tweaked your code to reproduce the exception that I am facing. Let
me know if you need more details.
thanks,
Mustaq
using System;
using Microsoft.Scripting;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
class Foo
{
public static void Main(string[] args)
{
AppDomain ad = AppDomain.CreateDomain("foo");
var engine = Python.CreateEngine(ad);
engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly);
var code = engine.CreateScriptSourceFromString(@"
import MbrBase
class C(MbrBase):
pass
a = C()
", SourceCodeKind.Statements);
var scope = engine.CreateScope();
code.Execute(scope);
Console.WriteLine("Trying to do it... {0}",
AppDomain.CurrentDomain.Id);
MbrBase mbr = (MbrBase)scope.GetVariable("a");
// MY CHANGES
string isSubClassCode = String.Format("issubclass({0},{1})", "C",
"MbrBase");
ScriptSource script =
engine.CreateScriptSourceFromString(isSubClassCode,
SourceCodeKind.Expression);
bool result = (bool)script.Execute(scope);
if (result == true)
{
ObjectOperations ops = engine.Operations;
object subClass = scope.GetVariable("C");
object instance = ops.Call(subClass);
mbr = instance as MbrBase;
}
// END OF MY CHANGE
mbr.DoItVirtually();
mbr.DoIt();
Console.ReadKey();
}
}
public class MbrBase : MarshalByRefObject
{
public virtual void DoItVirtually()
{
Console.WriteLine("Did it virtually {0}", AppDomain.CurrentDomain.Id
);
}
public void DoIt()
{
Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id);
}
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Jimmy.Schementi at microsoft.com Tue Apr 6 08:42:32 2010
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 6 Apr 2010 06:42:32 +0000
Subject: [IronPython] focus and selecting text in a TextBox with
IronPython
In-Reply-To: <3468cae11003241354l60bd213ejd449aa23921bf990@mail.gmail.com>
References: <3468cae11003241354l60bd213ejd449aa23921bf990@mail.gmail.com>
Message-ID: <1B42307CD4AADD438CDDA2FE1121CC921731DA0B@TK5EX14MBXC136.redmond.corp.microsoft.com>
Does the equivalent C#/VB code work? I'd think not; it's just a matter of using the TextBox selection APIs correctly. This sounds like a similar issue: http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/81b43024-6164-43c7-a6b6-e2f55c9412c8. Basically, I think you need to call Focus() again after selecting the text programmatically; I ran into the same issue while building my RubyConf demo: http://github.com/jschementi/rubyconf2009/blob/master/sketchscript/features/start.rb#L204.
~js
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ken MacDonald
Sent: Wednesday, March 24, 2010 1:54 PM
To: Discussion of IronPython
Subject: [IronPython] focus and selecting text in a TextBox with IronPython
I'm trying to capture the event of focus being shifted into a text box via mouse click, and would like to highlight the existing text, so that if I start typing the selected text will disappear. i.e. the the box initially contains "", I click into the box, "" is highlighted, and if I type "fred" the initial text will disappear, leaving only "fred". I can capture the focus with:
textbox.GotKeyboardFocus += name_keyboard_focus
but this handler is doing something wrong:
def name_keyboard_focus(self, sender, args):
#alert("got focus!")
textbox = self.control("NewName")
textbox.Focus()
textbox.SelectAll()
If I add:
textbox.Cut()
or:
alert(textbox.SelectedText)
at the end, it's obvious that the SelectAll() has worked, but the text is NOT highlighted, and if I type "fred" I get "fred" appended to the original text, "fred".
Any clues appreciated.
Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Jimmy.Schementi at microsoft.com Tue Apr 6 09:56:53 2010
From: Jimmy.Schementi at microsoft.com (Jimmy Schementi)
Date: Tue, 6 Apr 2010 07:56:53 +0000
Subject: [IronPython] WPF / ipy minimize weirdness?
In-Reply-To:
References:
Message-ID: <1B42307CD4AADD438CDDA2FE1121CC921731DC5C@TK5EX14MBXC136.redmond.corp.microsoft.com>
Can you manually minimize the modal dialog and then minimize the main window at all? The definition of a modal window is that you must interact with it first before returning to the main application, so I wouldn't think that you could minimize both, and then somehow ever get back to the parent window.
Also, you should try reproducing this with C# or VB; this sounds like it has nothing to do with IronPython, just an issue with using the API.
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Ken MacDonald
Sent: Monday, April 05, 2010 12:26 PM
To: Discussion of IronPython
Subject: [IronPython] WPF / ipy minimize weirdness?
Hi,
I have a WPF app and I'm trying to mess with WindowState. I have two windows, a modal selection dialog, and a main window. If I bring up the selection dialog with the main window in background, and minimize the selection dialog, it leaves the main window visible but you can't interact with it. So far, normal.
If I make a selection, the select dialog closes leaving the main window, and I can minimize the main window using the standard windows controls, and restore it from the taskbar. OK so far.
However, I want to get it working like this: if I minimize the selection dialog, I'd like to minimize the main window also. So, I added an event listener on StateChanged, something like:
def state_changed(...):
if self._w.WindowState == WindowState.Minimized:
main_window.WindowState = WindowState.Minimized
This captures the minimize event, both the selection dialog and main window minimize, BUT now I can't right-or-left-click on the minimized app to get it to restore, and have to kill the app using task manager. Also, it appears that instead of having two windows represented on the taskbar, only the main window is left - even though I should still have both the select dialog and the main window minimized.
Is there some magic state I need to set in the main window to be able to have it restore again? Why should it make a difference whether the minimize is done by the main window 'min' button, or by setting its WindowState?
Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From drken567 at gmail.com Tue Apr 6 16:10:16 2010
From: drken567 at gmail.com (Ken MacDonald)
Date: Tue, 6 Apr 2010 10:10:16 -0400
Subject: [IronPython] WPF / ipy minimize weirdness?
In-Reply-To: <1B42307CD4AADD438CDDA2FE1121CC921731DC5C@TK5EX14MBXC136.redmond.corp.microsoft.com>
References:
<1B42307CD4AADD438CDDA2FE1121CC921731DC5C@TK5EX14MBXC136.redmond.corp.microsoft.com>
Message-ID:
Hi Jimmy,
Thanks for the note!
I was thinking more about this last night - the app is a legacy thing I've
taken over, where the modal selection dialog is quite a heavy-weight entity
- it captures about the same amount of real estate as the underlying
application itself, with a dozen or more controls on it, and the user may be
fooling around with it for 4 or 5 minutes at a stretch. We've concluded that
it should really just present as a separate page on the app, rather than as
a modal dialog, and probably next release we'll be moving toward that; it
solves a stack of other interesting problems as well.
For the time being, we are trying to get to a point where someone may have
not finished messing with the selection dialog, and wants to just minimize
the whole thing (selection and main app window) in order to move to another
app. The 'other app' may be another copy of this one, just running on a
different data store, thus the need to get rid of (minimize completely) the
1st copy to avoid confusion! Obviously, when we move to a single window
design this problem goes away; right now just trying to get the two windows
in the app (if the selection dialog is active) to act "in unison".
In answer to your question, without any event handlers in place, I can
minimize the selection dialog using the standard Windows "_" control, which
leaves the main app window in view, but totally disabled - minimize, exit,
etc. are disabled along with any of the app's controls. Taskbar still had
two icons, one for the dialog and one for the main app, and I could restore
the dialog and continue.
When I added in an event handler, both the selection and main app windows
disappeared, with the modal dialog apparently completely gone (no taskbar
icon any more) and the underlying app still waiting for it, so it's taksbar
icon was completely disabled, unable to restore, cancel, anything.
Hope to get this to work in some fashion, but as I said, I'm going to be
turning this into a separate page for a single app at some point so I may
find some interim not-quite-what-they-want solution if this turns out to be
too much effort to get going.
Ken
On Tue, Apr 6, 2010 at 3:56 AM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:
> Can you manually minimize the modal dialog and then minimize the main
> window at all? The definition of a modal window is that you must interact
> with it first before returning to the main application, so I wouldn?t think
> that you could minimize both, and then somehow ever get back to the parent
> window.
>
>
>
> Also, you should try reproducing this with C# or VB; this sounds like it
> has nothing to do with IronPython, just an issue with using the API.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Ken MacDonald
> *Sent:* Monday, April 05, 2010 12:26 PM
> *To:* Discussion of IronPython
> *Subject:* [IronPython] WPF / ipy minimize weirdness?
>
>
>
> Hi,
> I have a WPF app and I'm trying to mess with WindowState. I have two
> windows, a modal selection dialog, and a main window. If I bring up the
> selection dialog with the main window in background, and minimize the
> selection dialog, it leaves the main window visible but you can't interact
> with it. So far, normal.
>
> If I make a selection, the select dialog closes leaving the main window,
> and I can minimize the main window using the standard windows controls, and
> restore it from the taskbar. OK so far.
>
> However, I want to get it working like this: if I minimize the selection
> dialog, I'd like to minimize the main window also. So, I added an event
> listener on StateChanged, something like:
>
> def state_changed(...):
> if self._w.WindowState == WindowState.Minimized:
> main_window.WindowState = WindowState.Minimized
>
> This captures the minimize event, both the selection dialog and main window
> minimize, BUT now I can't right-or-left-click on the minimized app to get it
> to restore, and have to kill the app using task manager. Also, it appears
> that instead of having two windows represented on the taskbar, only the main
> window is left - even though I should still have both the select dialog and
> the main window minimized.
>
> Is there some magic state I need to set in the main window to be able to
> have it restore again? Why should it make a difference whether the minimize
> is done by the main window 'min' button, or by setting its WindowState?
> Ken
>
> _______________________________________________
> 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 Apr 6 16:13:19 2010
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Tue, 06 Apr 2010 15:13:19 +0100
Subject: [IronPython] WPF / ipy minimize weirdness?
In-Reply-To:
References:
<1B42307CD4AADD438CDDA2FE1121CC921731DC5C@TK5EX14MBXC136.redmond.corp.microsoft.com>
Message-ID: <4BBB417F.7060401@voidspace.org.uk>
Hi Ken,
Weird behaviour of a "main window" when a modal dialog is displayed is
pretty normal I think. Just a drawback of modal dialogs.
Michael
On 06/04/2010 15:10, Ken MacDonald wrote:
> Hi Jimmy,
> Thanks for the note!
>
> I was thinking more about this last night - the app is a legacy thing
> I've taken over, where the modal selection dialog is quite a
> heavy-weight entity - it captures about the same amount of real estate
> as the underlying application itself, with a dozen or more controls on
> it, and the user may be fooling around with it for 4 or 5 minutes at a
> stretch. We've concluded that it should really just present as a
> separate page on the app, rather than as a modal dialog, and probably
> next release we'll be moving toward that; it solves a stack of other
> interesting problems as well.
>
> For the time being, we are trying to get to a point where someone may
> have not finished messing with the selection dialog, and wants to just
> minimize the whole thing (selection and main app window) in order to
> move to another app. The 'other app' may be another copy of this one,
> just running on a different data store, thus the need to get rid of
> (minimize completely) the 1st copy to avoid confusion! Obviously, when
> we move to a single window design this problem goes away; right now
> just trying to get the two windows in the app (if the selection dialog
> is active) to act "in unison".
>
> In answer to your question, without any event handlers in place, I can
> minimize the selection dialog using the standard Windows "_" control,
> which leaves the main app window in view, but totally disabled -
> minimize, exit, etc. are disabled along with any of the app's
> controls. Taskbar still had two icons, one for the dialog and one for
> the main app, and I could restore the dialog and continue.
>
> When I added in an event handler, both the selection and main app
> windows disappeared, with the modal dialog apparently completely gone
> (no taskbar icon any more) and the underlying app still waiting for
> it, so it's taksbar icon was completely disabled, unable to restore,
> cancel, anything.
>
> Hope to get this to work in some fashion, but as I said, I'm going to
> be turning this into a separate page for a single app at some point so
> I may find some interim not-quite-what-they-want solution if this
> turns out to be too much effort to get going.
> Ken
>
> On Tue, Apr 6, 2010 at 3:56 AM, Jimmy Schementi
> >
> wrote:
>
> Can you manually minimize the modal dialog and then minimize the
> main window at all? The definition of a modal window is that you
> must interact with it first before returning to the main
> application, so I wouldn?t think that you could minimize both, and
> then somehow ever get back to the parent window.
>
> Also, you should try reproducing this with C# or VB; this sounds
> like it has nothing to do with IronPython, just an issue with
> using the API.
>
> *From:* users-bounces at lists.ironpython.com
>
> [mailto:users-bounces at lists.ironpython.com
> ] *On Behalf Of *Ken
> MacDonald
> *Sent:* Monday, April 05, 2010 12:26 PM
> *To:* Discussion of IronPython
> *Subject:* [IronPython] WPF / ipy minimize weirdness?
>
> Hi,
> I have a WPF app and I'm trying to mess with WindowState. I have
> two windows, a modal selection dialog, and a main window. If I
> bring up the selection dialog with the main window in background,
> and minimize the selection dialog, it leaves the main window
> visible but you can't interact with it. So far, normal.
>
> If I make a selection, the select dialog closes leaving the main
> window, and I can minimize the main window using the standard
> windows controls, and restore it from the taskbar. OK so far.
>
> However, I want to get it working like this: if I minimize the
> selection dialog, I'd like to minimize the main window also. So, I
> added an event listener on StateChanged, something like:
>
> def state_changed(...):
> if self._w.WindowState == WindowState.Minimized:
> main_window.WindowState = WindowState.Minimized
>
> This captures the minimize event, both the selection dialog and
> main window minimize, BUT now I can't right-or-left-click on the
> minimized app to get it to restore, and have to kill the app using
> task manager. Also, it appears that instead of having two windows
> represented on the taskbar, only the main window is left - even
> though I should still have both the select dialog and the main
> window minimized.
>
> Is there some magic state I need to set in the main window to be
> able to have it restore again? Why should it make a difference
> whether the minimize is done by the main window 'min' button, or
> by setting its WindowState?
> Ken
>
>
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From drken567 at gmail.com Tue Apr 6 16:14:03 2010
From: drken567 at gmail.com (Ken MacDonald)
Date: Tue, 6 Apr 2010 10:14:03 -0400
Subject: [IronPython] focus and selecting text in a TextBox with
IronPython
In-Reply-To: <1B42307CD4AADD438CDDA2FE1121CC921731DA0B@TK5EX14MBXC136.redmond.corp.microsoft.com>
References: <3468cae11003241354l60bd213ejd449aa23921bf990@mail.gmail.com>
<1B42307CD4AADD438CDDA2FE1121CC921731DA0B@TK5EX14MBXC136.redmond.corp.microsoft.com>
Message-ID:
Hi Jimmy,
Thanks; this thread looks quite interesting and very close to what I want to
do. Off chasing something else after I implemented a kind-of-lame
workaround, but this looks like an excellent place to make some more
progress when I get back onto this problem.
Ken
On Tue, Apr 6, 2010 at 2:42 AM, Jimmy Schementi <
Jimmy.Schementi at microsoft.com> wrote:
> Does the equivalent C#/VB code work? I?d think not; it?s just a matter of
> using the TextBox selection APIs correctly. This sounds like a similar
> issue:
> http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/81b43024-6164-43c7-a6b6-e2f55c9412c8.
> Basically, I think you need to call Focus() again after selecting the text
> programmatically; I ran into the same issue while building my RubyConf demo:
>
> http://github.com/jschementi/rubyconf2009/blob/master/sketchscript/features/start.rb#L204.
>
>
>
>
> ~js
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *Ken MacDonald
> *Sent:* Wednesday, March 24, 2010 1:54 PM
> *To:* Discussion of IronPython
> *Subject:* [IronPython] focus and selecting text in a TextBox with
> IronPython
>
>
>
> I'm trying to capture the event of focus being shifted into a text box via
> mouse click, and would like to highlight the existing text, so that if I
> start typing the selected text will disappear. i.e. the the box initially
> contains "", I click into the box, "" is
> highlighted, and if I type "fred" the initial text will disappear, leaving
> only "fred". I can capture the focus with:
>
> textbox.GotKeyboardFocus += name_keyboard_focus
>
> but this handler is doing something wrong:
>
> def name_keyboard_focus(self, sender, args):
> #alert("got focus!")
> textbox = self.control("NewName")
> textbox.Focus()
> textbox.SelectAll()
>
> If I add:
>
> textbox.Cut()
>
> or:
> alert(textbox.SelectedText)
>
> at the end, it's obvious that the SelectAll() has worked, but the text is
> NOT highlighted, and if I type "fred" I get "fred" appended to the original
> text, "fred".
>
> Any clues appreciated.
> Ken
>
> _______________________________________________
> 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 mustaq2001 at gmail.com Wed Apr 7 07:10:39 2010
From: mustaq2001 at gmail.com (mohammad mustaq)
Date: Wed, 7 Apr 2010 10:40:39 +0530
Subject: [IronPython] IronPython.Runtime.Types.PythonType Is not marked
as Serializable Exception
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD394D33AA@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <1b9598291003292013x64ae07a3j9bb9290a058f9d98@mail.gmail.com>
<1A472770E042064698CB5ADC83A12ACD394D33AA@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID:
Hi Dino,
If have tweaked your code to reproduce the exception that I am facing. Let
me know if you need more details.
thanks,
Mustaq
using System;
using Microsoft.Scripting;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
class Foo
{
public static void Main(string[] args)
{
AppDomain ad = AppDomain.CreateDomain("foo");
var engine = Python.CreateEngine(ad);
engine.Runtime.LoadAssembly(
typeof(MbrBase).Assembly);
var code = engine.CreateScriptSourceFromString(@"
import MbrBase
class C(MbrBase):
pass
a = C()
", SourceCodeKind.Statements);
var scope = engine.CreateScope();
code.Execute(scope);
Console.WriteLine("Trying to do it... {0}",
AppDomain.CurrentDomain.Id );
MbrBase mbr = (MbrBase)scope.GetVariable("a");
// MY CHANGES
string isSubClassCode = String.Format("issubclass({0},{1})", "C",
"MbrBase");
ScriptSource script =
engine.CreateScriptSourceFromString(isSubClassCode,
SourceCodeKind.Expression);
bool result = (bool)script.Execute(scope);
if (result == true)
{
ObjectOperations ops = engine.Operations;
object subClass = scope.GetVariable("C");
object instance = ops.Call(subClass);
mbr = instance as MbrBase;
}
// END OF MY CHANGE
mbr.DoItVirtually();
mbr.DoIt();
Console.ReadKey();
}
}
public class MbrBase : MarshalByRefObject
{
public virtual void DoItVirtually()
{
Console.WriteLine("Did it virtually {0}",
AppDomain.CurrentDomain.Id
);
}
public void DoIt()
{
Console.WriteLine("Did it {0}",
AppDomain.CurrentDomain.Id
);
}
}
On Tue, Mar 30, 2010 at 10:12 PM, Dino Viehland wrote:
> This works for me w/ 2.6. I?ve included my simple repro below which
> creates a new script engine in a remote app domain, loads my assembly in,
> runs some code which subclasses the MBRO base class, instantiates an
> instance of this class, and then calls it from a remote app domain. The key
> thing here is that when an MBRO is involved a PythonType should not need to
> be serialized ? the type should live in the remote app domain and all
> execution of that code should also happen in the remote app domain where we
> have access to the local PythonType object. Are you also subclassing types
> which don?t derive from MBRO? It might help to run IronPython w/
> -X:ExceptionDetail if the exception is propagating through IronPython ?
> that?ll give a better stack trace to understand what?s going on. Or if you
> can tweak the simple repro below to match the behavior you?re seeing that?d
> be helpful as well.
>
>
>
> using System;
>
> using Microsoft.Scripting;
>
> using IronPython.Hosting;
>
>
>
> class Foo {
>
> public static void Main(string[] args) {
>
> AppDomain ad = AppDomain.CreateDomain("foo");
>
> var engine = Python.CreateEngine(ad);
>
> engine.Runtime.LoadAssembly(typeof(MbrBase).Assembly);
>
>
>
> var code = engine.CreateScriptSourceFromString(@"
>
> import MbrBase
>
> class C(MbrBase):
>
> pass
>
>
>
> a = C()
>
> ", SourceCodeKind.Statements);
>
>
>
> var scope = engine.CreateScope();
>
> code.Execute(scope);
>
>
>
> Console.WriteLine("Trying to do it... {0}",
> AppDomain.CurrentDomain.Id);
>
> MbrBase mbr = (MbrBase)scope.GetVariable("a");
>
> mbr.DoItVirtually();
>
> mbr.DoIt();
>
> }
>
> }
>
>
>
> public class MbrBase : MarshalByRefObject {
>
> public virtual void DoItVirtually() {
>
> Console.WriteLine("Did it virtually {0}",
> AppDomain.CurrentDomain.Id);
>
> }
>
>
>
> public void DoIt() {
>
> Console.WriteLine("Did it {0}", AppDomain.CurrentDomain.Id);
>
> }
>
> }
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *mohammad mustaq
> *Sent:* Monday, March 29, 2010 8:13 PM
> *To:* users at lists.ironpython.com
> *Subject:* [IronPython] IronPython.Runtime.Types.PythonType Is not marked
> as Serializable Exception
>
>
>
> Hi,
>
> I have IronPython embedded in my C# application. I face issues while
> creating the python engine in a different appdomain.
>
> It is imposed that every class in IronPython inherit the .NET base class
> say ClassA. ClassA is derived from MarshalByRefObj as I need to pass an
> instance of this class to a new appdomain.
> I create a new appdomain and pass the instance of ClassA to this Appdomain.
> While calling a method in python class through the instance of ClassA I get
> an exception mentioning that "Type 'IronPython.Runtime.Types.PythonTyp
>
> e' in Assembly 'IronPython, Version=2.0.0.0, Culture=neutral,
> PublicKeyToken=31bf3856ad364e35' is not marked as serializable".
>
> How do I Serialize this PythonType. One way that i know is to modify the
> IronPython source and mark the required types as Serializable (but i do not
> know where it will lead to and its consequences). Could you please suggest a
> way to perform the required operation. Should you need more details let me
> know.
>
> thanks,
> Mustaq
>
> P.S. I have used both IronPython 2.0 and 2.6.
>
> _______________________________________________
> 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 beppler at gmail.com Wed Apr 7 16:26:26 2010
From: beppler at gmail.com (Carlos Alberto Costa Beppler)
Date: Wed, 7 Apr 2010 11:26:26 -0300
Subject: [IronPython] socket.getfqdn problem on 2.6.1 RC1.
Message-ID:
Hi, I?m trying to use the HTTPServer class from de BaseHTTPServer.py
on standard library on IronPython 2.6.1 RC1.
But the server stops with an socket exception on startup as shown bellow.
C:\Program Files\Tools>ipy
IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.3607
Type "help", "copyright", "credits" or "license" for more information.
>>> import BaseHTTPServer
>>> BaseHTTPServer.test()
Traceback (most recent call last):
File "", line 1, in
File "C:\Program Files\IronPython\Lib\BaseHTTPServer.py", line 584, in test
File "C:\Program Files\IronPython\Lib\SocketServer.py", line 400, in __init__
File "C:\Program Files\IronPython\Lib\BaseHTTPServer.py", line 110, in server_
bind
ValueError: IPv4 address 0.0.0.0 and IPv6 address ::0 are unspecified addresses
that cannot be used as a target address.
Parameter name: hostNameOrAddress
This is because the method getfqdn of the socket class is blowing up
when the string '0.0.0.0' is passed to it. For example:
C:\Program Files\Tools>ipy
IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.3607
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getfqdn('0.0.0.0')
Traceback (most recent call last):
File "", line 1, in
ValueError: IPv4 address 0.0.0.0 and IPv6 address ::0 are unspecified addresses
that cannot be used as a target address.
Parameter name: hostNameOrAddress
On CPython the same call returns the current host name, like bellow.
C:\Users\beppler>python
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getfqdn('0.0.0.0')
'Beppler.mps.interno'
>>>
Is it possible to fix this for the 2.6.1 release?
From stephen.p.lepisto at intel.com Wed Apr 7 16:36:10 2010
From: stephen.p.lepisto at intel.com (Lepisto, Stephen P)
Date: Wed, 7 Apr 2010 07:36:10 -0700
Subject: [IronPython] socket.getfqdn problem on 2.6.1 RC1.
In-Reply-To:
References:
Message-ID: <6AF28EB9F93A354894F2F3916DF6F96E0C9C7447AD@orsmsx510.amr.corp.intel.com>
In IronPython, using socket.getfqdn('127.0.0.1') returns the local host name. Under CPython, this always returns 'localhost'.
The CPython documentation for getfqdn() does explicitly state "If name is omitted or empty, it is interpreted as the local host."
Therefore, if you change your call to leave out the '0.0.0.0', then the code will behave the same on both CPython and IronPython.
IronPython:
>>> import socket
>>> socket.getfqdn()
mydomain.name.here
CPython:
>>> import socket
>>> socket.getfqdn()
mydomain.name.here
-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Carlos Alberto Costa Beppler
Sent: Wednesday, April 07, 2010 7:26 AM
To: Discussion of IronPython
Subject: [IronPython] socket.getfqdn problem on 2.6.1 RC1.
Hi, I?m trying to use the HTTPServer class from de BaseHTTPServer.py
on standard library on IronPython 2.6.1 RC1.
But the server stops with an socket exception on startup as shown bellow.
C:\Program Files\Tools>ipy
IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.3607
Type "help", "copyright", "credits" or "license" for more information.
>>> import BaseHTTPServer
>>> BaseHTTPServer.test()
Traceback (most recent call last):
File "", line 1, in
File "C:\Program Files\IronPython\Lib\BaseHTTPServer.py", line 584, in test
File "C:\Program Files\IronPython\Lib\SocketServer.py", line 400, in __init__
File "C:\Program Files\IronPython\Lib\BaseHTTPServer.py", line 110, in server_
bind
ValueError: IPv4 address 0.0.0.0 and IPv6 address ::0 are unspecified addresses
that cannot be used as a target address.
Parameter name: hostNameOrAddress
This is because the method getfqdn of the socket class is blowing up
when the string '0.0.0.0' is passed to it. For example:
C:\Program Files\Tools>ipy
IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.3607
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getfqdn('0.0.0.0')
Traceback (most recent call last):
File "", line 1, in
ValueError: IPv4 address 0.0.0.0 and IPv6 address ::0 are unspecified addresses
that cannot be used as a target address.
Parameter name: hostNameOrAddress
On CPython the same call returns the current host name, like bellow.
C:\Users\beppler>python
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getfqdn('0.0.0.0')
'Beppler.mps.interno'
>>>
Is it possible to fix this for the 2.6.1 release?
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
From beppler at gmail.com Wed Apr 7 16:39:22 2010
From: beppler at gmail.com (Carlos Alberto Costa Beppler)
Date: Wed, 7 Apr 2010 11:39:22 -0300
Subject: [IronPython] socket.getfqdn problem on 2.6.1 RC1.
In-Reply-To: <6AF28EB9F93A354894F2F3916DF6F96E0C9C7447AD@orsmsx510.amr.corp.intel.com>
References:
<6AF28EB9F93A354894F2F3916DF6F96E0C9C7447AD@orsmsx510.amr.corp.intel.com>
Message-ID:
The problem is that the HTTPServer from standard lib is doing the call
on line 109-110 of the file BaseHTTPServer.py on method server_bind.
See the code bellow.
class HTTPServer(SocketServer.TCPServer):
allow_reuse_address = 1 # Seems to make sense in testing environment
def server_bind(self):
"""Override server_bind to store the server name."""
SocketServer.TCPServer.server_bind(self)
host, port = self.socket.getsockname()[:2]
self.server_name = socket.getfqdn(host)
self.server_port = port
The host variable gets '0.0.0.0' and when the call to socket.getfqdn
is made the exception is thrown.
On Wed, Apr 7, 2010 at 11:36, Lepisto, Stephen P
wrote:
> In IronPython, using socket.getfqdn('127.0.0.1') returns the local host name. ?Under CPython, this always returns 'localhost'.
>
> The CPython documentation for getfqdn() does explicitly state "If name is omitted or empty, it is interpreted as the local host."
>
> Therefore, if you change your call to leave out the '0.0.0.0', then the code will behave the same on both CPython and IronPython.
>
> IronPython:
>>>> import socket
>>>> socket.getfqdn()
> mydomain.name.here
>
> CPython:
>>>> import socket
>>>> socket.getfqdn()
> mydomain.name.here
>
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Carlos Alberto Costa Beppler
> Sent: Wednesday, April 07, 2010 7:26 AM
> To: Discussion of IronPython
> Subject: [IronPython] socket.getfqdn problem on 2.6.1 RC1.
>
> Hi, I?m trying to use the HTTPServer class from de BaseHTTPServer.py
> on standard library on IronPython 2.6.1 RC1.
>
> But the server stops with an socket exception on startup as shown bellow.
>
> C:\Program Files\Tools>ipy
> IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.3607
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import BaseHTTPServer
>>>> BaseHTTPServer.test()
> Traceback (most recent call last):
> ?File "", line 1, in
> ?File "C:\Program Files\IronPython\Lib\BaseHTTPServer.py", line 584, in test
> ?File "C:\Program Files\IronPython\Lib\SocketServer.py", line 400, in __init__
> ?File "C:\Program Files\IronPython\Lib\BaseHTTPServer.py", line 110, in server_
> bind
> ValueError: IPv4 address 0.0.0.0 and IPv6 address ::0 are unspecified addresses
> that cannot be used as a target address.
> Parameter name: hostNameOrAddress
>
> This is because the method getfqdn of the socket class is blowing up
> when the string '0.0.0.0' is passed to it. For example:
>
> C:\Program Files\Tools>ipy
> IronPython 2.6.1 (2.6.10920.0) on .NET 2.0.50727.3607
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import socket
>>>> socket.getfqdn('0.0.0.0')
> Traceback (most recent call last):
> ?File "", line 1, in
> ValueError: IPv4 address 0.0.0.0 and IPv6 address ::0 are unspecified addresses
> that cannot be used as a target address.
> Parameter name: hostNameOrAddress
>
> On CPython the same call returns the current host name, like bellow.
>
> C:\Users\beppler>python
> Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import socket
>>>> socket.getfqdn('0.0.0.0')
> 'Beppler.mps.interno'
>>>>
>
>
> Is it possible to fix this for the 2.6.1 release?
> _______________________________________________
> 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 merllab at microsoft.com Wed Apr 7 17:52:38 2010
From: merllab at microsoft.com (merllab at microsoft.com)
Date: Wed, 7 Apr 2010 08:52:38 -0700
Subject: [IronPython] IronPython 2.6 CodePlex Source Update
Message-ID: <2cd0a4ed-bce5-4c75-abb5-d62f2ccd6188@tk5-exsmh-c101.redmond.corp.microsoft.com>
This is an automated email letting you know that sources
have recently been pushed out. You can download these newer
sources directly from http://ironpython.codeplex.com/SourceControl/changeset/view/65328.
ADDED SOURCES
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Microsoft.Scripting.Core.DlrBranch.csproj
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Microsoft.Scripting.ExtensionAttribute.DlrBranch.csproj
MODIFIED SOURCES
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Microsoft.Scripting.Core.DlrBranch.csproj
$/IronPython/IronPython_Main/Src/Runtime/Microsoft.Scripting.Core/Microsoft.Scripting.ExtensionAttribute.DlrBranch.csproj
From jdhardy at gmail.com Thu Apr 8 17:29:50 2010
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 8 Apr 2010 09:29:50 -0600
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD394EF8FE@TK5EX14MBXC118.redmond.corp.microsoft.com>
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EF8FE@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID:
On Fri, Apr 2, 2010 at 8:06 PM, Dino Viehland wrote:
> Can you clear the exception data from the server at all?
ExceptionHelpers.DynamicStackFrames never climbs above 1 (as far as I
can tell), yet there's a consistent leak of about 35k/request. That
just doesn't seem to make sense based on what I found with windbg, so
I'm stumped.
- Jeff
From cgencer at gmail.com Thu Apr 8 18:38:23 2010
From: cgencer at gmail.com (Can Gencer)
Date: Thu, 8 Apr 2010 18:38:23 +0200
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
<1A472770E042064698CB5ADC83A12ACD394E46D9@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EF8FE@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID:
On Thu, Apr 8, 2010 at 5:29 PM, Jeff Hardy wrote:
> On Fri, Apr 2, 2010 at 8:06 PM, Dino Viehland wrote:
>> Can you clear the exception data from the server at all?
>
> ExceptionHelpers.DynamicStackFrames never climbs above 1 (as far as I
> can tell), yet there's a consistent leak of about 35k/request. That
> just doesn't seem to make sense based on what I found with windbg, so
> I'm stumped.
>
> - Jeff
I've noticed there was a leak in the NWSGI implementation regarding
the input/output streams, i.e. they were never GC'd. It could be due
to the way the stream -> file conversion is done.
Regards,
Can
From jdhardy at gmail.com Thu Apr 8 19:32:57 2010
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 8 Apr 2010 11:32:57 -0600
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EF8FE@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID:
On Thu, Apr 8, 2010 at 10:38 AM, Can Gencer wrote:
> I've noticed there was a leak in the NWSGI implementation regarding
> the input/output streams, i.e. they were never GC'd. It could be due
> to the way the stream -> file conversion is done.
Wouldn't surprise me; that's kind of an ugly piece of code. There's a
few spots where NWSGI doesn't interact with CodeContexts correctly,
because there wasn't really a good story around them - now I'd just
use SharedContext, assuming I can *find* it again :).
But there must be something else, in NWSGI or IronPython, to account
for 35k/request.
- Jeff
From pjaganathan at gmail.com Thu Apr 8 19:35:46 2010
From: pjaganathan at gmail.com (Prasanna Jaganathan)
Date: Thu, 8 Apr 2010 23:05:46 +0530
Subject: [IronPython] IronPython Tools for Visual Studio
Message-ID:
Hi
I am trying to get a good IDE for working with Iron Python, I chanced upon
this page and found about IronPython Tools for Visual Studio.
http://us.pycon.org/media/2010/talkdata/PyCon2010/009/IronPython_Tools_for_Visual_Studio_Walkthrough.pdf
I
have installed Visual Studio 2010 beta and would like to install this
plugin. Can you point me to a place where I can download this?
Thank you very much!
Regards
Prasanna
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From cgencer at gmail.com Thu Apr 8 19:41:30 2010
From: cgencer at gmail.com (Can Gencer)
Date: Thu, 8 Apr 2010 19:41:30 +0200
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EF8FE@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID:
On Thu, Apr 8, 2010 at 7:32 PM, Jeff Hardy wrote:
> On Thu, Apr 8, 2010 at 10:38 AM, Can Gencer wrote:
>> I've noticed there was a leak in the NWSGI implementation regarding
>> the input/output streams, i.e. they were never GC'd. It could be due
>> to the way the stream -> file conversion is done.
>
> Wouldn't surprise me; that's kind of an ugly piece of code. There's a
> few spots where NWSGI doesn't interact with CodeContexts correctly,
> because there wasn't really a good story around them - now I'd just
> use SharedContext, assuming I can *find* it again :).
>
> But there must be something else, in NWSGI or IronPython, to account
> for 35k/request.
>
I did my debugging like this..
I set up a url such as http://server/gc where if you would go there it
would call GC.Collect() and GC.WaitForPendingFinalizers() a few times
Then did a few requests, and call the GC url and use windbg with
!dumpheap -stat and write down the number and size of the largest
objects. Do a few more requests, call the GC url again and use windbg
again with the stat, and then use !dumpheap -mt to get all instances
of the type that is growing in size most, and then randomly call
!gcroot on some to find where the reference is being held.
/Can
From Marty.Nelson at symyx.com Thu Apr 8 19:45:14 2010
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Thu, 8 Apr 2010 10:45:14 -0700
Subject: [IronPython] IronPython Tools for Visual Studio
In-Reply-To:
References:
Message-ID: <8C12A2BD8CFE894C891514267B55A2B511456D79@srv-sc-mail.symyx.com>
We offer extensive Iron Python extension points for our customers in our
application and would be very interested in this technology as well.
Marty Nelson
Symyx Technologies.
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Prasanna
Jaganathan
Sent: Thursday, April 08, 2010 10:36 AM
To: users at lists.ironpython.com
Subject: [IronPython] IronPython Tools for Visual Studio
Hi
I am trying to get a good IDE for working with Iron Python, I chanced
upon this page and found about IronPython Tools for Visual Studio.
http://us.pycon.org/media/2010/talkdata/PyCon2010/009/IronPython_Tools_f
or_Visual_Studio_Walkthrough.pdf
I have installed Visual Studio 2010 beta and would like to install this
plugin. Can you point me to a place where I can download this?
Thank you very much!
Regards
Prasanna
=======
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 jdhardy at gmail.com Thu Apr 8 19:55:08 2010
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 8 Apr 2010 11:55:08 -0600
Subject: [IronPython] IronPython with CherryPy through WSGI Memory issue
In-Reply-To:
References:
<1A472770E042064698CB5ADC83A12ACD394E638A@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EE7E1@TK5EX14MBXC118.redmond.corp.microsoft.com>
<1A472770E042064698CB5ADC83A12ACD394EF8FE@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID:
On Thu, Apr 8, 2010 at 11:41 AM, Can Gencer wrote:
> I did my debugging like this..
>
> I set up a url such as http://server/gc where if you would go there it
> would call GC.Collect() and GC.WaitForPendingFinalizers() a few times
>
> Then did a few requests, and call the GC url and use windbg with
> !dumpheap -stat and write down the number and size of the largest
> objects. Do a few more requests, call the GC url again and use windbg
> again with the stat, and then use !dumpheap -mt to get all instances
> of the type that is growing in size most, and then randomly call
> !gcroot on some to find where the reference is being held.
That's pretty much what I did as well. Most of the objects were
strings, byte[]s, dictionary buckets - stuff that's used just about
everywhere. Trying to get a meaningful set of !gcroot samples from
amongst 125 000 dictionaries manually is a bit difficult :|.
My hope is that somewhere in that list there is an object that leaks 1
instance per request, so that I can match it up with the number of
requests, and work from it to figure out what's going on.
- Jeff
From jdhardy at gmail.com Thu Apr 8 19:57:30 2010
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 8 Apr 2010 11:57:30 -0600
Subject: [IronPython] IronPython Tools for Visual Studio
In-Reply-To:
References:
Message-ID:
On Thu, Apr 8, 2010 at 11:35 AM, Prasanna Jaganathan
wrote:
> Hi
> I am trying to get a good IDE for working with Iron Python, I chanced upon
> this page and found about?IronPython Tools for Visual Studio.
> http://us.pycon.org/media/2010/talkdata/PyCon2010/009/IronPython_Tools_for_Visual_Studio_Walkthrough.pdf
> I have installed Visual Studio 2010 beta and would like to install this
> plugin. Can you point me to a place where I can download this?
> Thank you very much!
I believe the first public release will roughly coincide with the RTM
of Visual Studio 2010, which is Monday, April 12, 2010. So, it should
be available next week. Hopefully.
- Jeff
From dinov at microsoft.com Thu Apr 8 19:59:50 2010
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 8 Apr 2010 17:59:50 +0000
Subject: [IronPython] IronPython Tools for Visual Studio
In-Reply-To: <8C12A2BD8CFE894C891514267B55A2B511456D79@srv-sc-mail.symyx.com>
References:
<8C12A2BD8CFE894C891514267B55A2B511456D79@srv-sc-mail.symyx.com>
Message-ID: <1A472770E042064698CB5ADC83A12ACD3950A8DB@TK5EX14MBXC118.redmond.corp.microsoft.com>
It's not yet publicly available - the preview was given out exclusively to PyCon attendees on a CD. We'll be putting out an updated version within a couple of weeks after VS 2010 launches which is April 12th.
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Marty Nelson
Sent: Thursday, April 08, 2010 10:45 AM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython Tools for Visual Studio
We offer extensive Iron Python extension points for our customers in our application and would be very interested in this technology as well.
Marty Nelson
Symyx Technologies.
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Prasanna Jaganathan
Sent: Thursday, April 08, 2010 10:36 AM
To: users at lists.ironpython.com
Subject: [IronPython] IronPython Tools for Visual Studio
Hi
I am trying to get a good IDE for working with Iron Python, I chanced upon this page and found about IronPython Tools for Visual Studio.
http://us.pycon.org/media/2010/talkdata/PyCon2010/009/IronPython_Tools_for_Visual_Studio_Walkthrough.pdf
I have installed Visual Studio 2010 beta and would like to install this plugin. Can you point me to a place where I can download this?
Thank you very much!
Regards
Prasanna
=======
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 loocas at duber.cz Thu Apr 8 20:11:54 2010
From: loocas at duber.cz (=?UTF-8?B?THVrw6HFoSBEdWLEm2Rh?=)
Date: Thu, 08 Apr 2010 20:11:54 +0200
Subject: [IronPython] IronPython Tools for Visual Studio
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD3950A8DB@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: <8C12A2BD8CFE894C891514267B55A2B511456D79@srv-sc-mail.symyx.com>
<1A472770E042064698CB5ADC83A12ACD3950A8DB@TK5EX14MBXC118.redmond.corp.microsoft.com>
Message-ID: <4BBE1C6A.8000102@duber.cz>
Oh man! I can't wait for the IPy support in VS2010!
So, you're saying it should be out in a couple of weeks? Not
months?
I'm especially eager to get my hands on a really functional, usable
and usful IDE for GUI development.
Thumbs up to you involved in the development of these tools!
Luk?? Dub?da
Director
[T] +420 602 444 164
duber studio(tm)
[M] info at duber.cz
[W] http://www.duber.cz
[A] R.A.Dvorsk?ho 601, Praha 10
[A] 10900, Czech Republic, Europe
Dino Viehland wrote:
> It?s not yet publicly available ? the preview was given out exclusively
> to PyCon attendees on a CD. We?ll be putting out an updated version
> within a couple of weeks after VS 2010 launches which is April 12^th .
>
>
>
> *From:* users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Marty Nelson
> *Sent:* Thursday, April 08, 2010 10:45 AM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] IronPython Tools for Visual Studio
>
>
>
> We offer extensive Iron Python extension points for our customers in our
> application and would be very interested in this technology as well.
>
>
>
> Marty Nelson
>
> Symyx Technologies.
>
>
>
> *From:* users-bounces at lists.ironpython.com
> [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Prasanna
> Jaganathan
> *Sent:* Thursday, April 08, 2010 10:36 AM
> *To:* users at lists.ironpython.com
> *Subject:* [IronPython] IronPython Tools for Visual Studio
>
>
>
> Hi
>
>
>
> I am trying to get a good IDE for working with Iron Python, I chanced
> upon this page and found about IronPython Tools for Visual Studio.
>
> http://us.pycon.org/media/2010/talkdata/PyCon2010/009/IronPython_Tools_for_Visual_Studio_Walkthrough.pdf
>
> I have installed Visual Studio 2010 beta and would like to install this
> plugin. Can you point me to a place where I can download this?
>
>
>
> Thank you very much!
>
>
>
> Regards
>
> Prasanna
>
> =======
> 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
From dinov at microsoft.com Thu Apr 8 20:15:40 2010
From: dinov at microsoft.com (Dino Viehland)
Date: Thu, 8 Apr 2010 18:15:40 +0000
Subject: [IronPython] IronPython Tools for Visual Studio
In-Reply-To: <4BBE1C6A.8000102@duber.cz>
References:
<8C12A2BD8CFE894C891514267B55A2B511456D79@srv-sc-mail.symyx.com>
<1A472770E042064698CB5ADC83A12ACD3950A8DB@TK5EX14MBXC118.redmond.corp.microsoft.com>
<4BBE1C6A.8000102@duber.cz>
Message-ID: <1A472770E042064698CB5ADC83A12ACD3950A972@TK5EX14MBXC118.redmond.corp.microsoft.com>
Yes - weeks not months. It is still a work in progress so this isn't a
final v1.0 or something (more like 0.2) but it will be publicly downloadable.
We're aiming for a v1 by the end of the year.
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-
> bounces at lists.ironpython.com] On Behalf Of Luk?? Dubeda
> Sent: Thursday, April 08, 2010 11:12 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython Tools for Visual Studio
>
> Oh man! I can't wait for the IPy support in VS2010!
>
> So, you're saying it should be out in a couple of weeks? Not
> months?
>
> I'm especially eager to get my hands on a really functional, usable
> and usful IDE for GUI development.
>
> Thumbs up to you involved in the development of these tools!
>
> Luk?? Dub?da
> Director
> [T] +420 602 444 164
>
> duber studio(tm)
> [M] info at duber.cz
> [W] http://www.duber.cz
>
> [A] R.A.Dvorsk?ho 601, Praha 10
> [A] 10900, Czech Republic, Europe
>
> Dino Viehland wrote:
> > It?s not yet publicly available ? the preview was given out
> exclusively
> > to PyCon attendees on a CD. We?ll be putting out an updated version
> > within a couple of weeks after VS 2010 launches which is April 12^th
> .
> >
> >
> >
> > *From:* users-bounces at lists.ironpython.com
> > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Marty
> Nelson
> > *Sent:* Thursday, April 08, 2010 10:45 AM
> > *To:* Discussion of IronPython
> > *Subject:* Re: [IronPython] IronPython Tools for Visual Studio
> >
> >
> >
> > We offer extensive Iron Python extension points for our customers in
> our
> > application and would be very interested in this technology as well.
> >
> >
> >
> > Marty Nelson
> >
> > Symyx Technologies.
> >
> >
> >
> > *From:* users-bounces at lists.ironpython.com
> > [mailto:users-bounces at lists.ironpython.com] *On Behalf Of *Prasanna
> > Jaganathan
> > *Sent:* Thursday, April 08, 2010 10:36 AM
> > *To:* users at lists.ironpython.com
> > *Subject:* [IronPython] IronPython Tools for Visual Studio
> >
> >
> >
> > Hi
> >
> >
> >
> > I am trying to get a good IDE for working with Iron Python, I chanced
> > upon this page and found about IronPython Tools for Visual Studio.
> >
> >
> http://us.pycon.org/media/2010/talkdata/PyCon2010/009/IronPython_Tools_
> for_Visual_Studio_Walkthrough.pdf
> >
> > I have installed Visual Studio 2010 beta and would like to install
> this
> > plugin. Can you point me to a place where I can download this?
> >
> >
> >
> > Thank you very much!
> >
> >
> >
> > Regards
> >
> > Prasanna
> >
> > =======
> > 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
From Marty.Nelson at symyx.com Thu Apr 8 20:51:33 2010
From: Marty.Nelson at symyx.com (Marty Nelson)
Date: Thu, 8 Apr 2010 11:51:33 -0700
Subject: [IronPython] IronPython Tools for Visual Studio
In-Reply-To: <1A472770E042064698CB5ADC83A12ACD3950A972@TK5EX14MBXC118.redmond.corp.microsoft.com>
References: