From sepatan at sibmail.com Mon Oct 1 10:38:08 2012
From: sepatan at sibmail.com (sepatan at sibmail.com)
Date: Mon, 1 Oct 2012 15:38:08 +0700 (NOVT)
Subject: [Ironpython-users] How to use sys._getframe () in IronPython in
Silverlight
Message-ID: <39458.83.172.33.173.1349080688.squirrel@www.sibmail.com>
How to specify the startup IronPython in Silverlight. Should set -X:Frames
in the true.
What you need to edit?
1) languages.config, AppManifest.xaml in dlr.xap
2) or it may be in a tag initParams HTML:
?
I want to use sys._getframe (). Can anyone help?
From pawel.jasinski at gmail.com Mon Oct 1 11:15:37 2012
From: pawel.jasinski at gmail.com (Pawel Jasinski)
Date: Mon, 1 Oct 2012 11:15:37 +0200
Subject: [Ironpython-users] How to find out -X:options passed to ipy
Message-ID:
hi,
is there a way to find out things passed to ipy.exe with -X:whatever
analog to sys.flags?
I would like to detect when -X:Frames or -X:FullFrames are provided
and pass it to subprocess.
thanks
pawel
From no_reply at codeplex.com Mon Oct 1 13:06:29 2012
From: no_reply at codeplex.com (no_reply at codeplex.com)
Date: 1 Oct 2012 04:06:29 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 9/30/2012
Message-ID:
Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New issue] object.__new__() takes no parameters - unexcpected __init__ considered
----------------------------------------------
ISSUES
1. [New issue] object.__new__() takes no parameters - unexcpected __init__ considered
http://ironpython.codeplex.com/workitem/33185
User paweljasinski has proposed the issue:
"I have spotted difference between IronPython and cpython. It has to do with calling of the __init__ in superclasses when multiple inheritance is used. In the test case below IronPython insist on calling __init__ where cpython doesn't.
class OldStyle:
def __init__(self, arg):
print "OldStyle"
class NewStyleNoInit1(OldStyle,object):
pass
NewStyleNoInit1(0)
IronPython prints:
Traceback (most recent call last):
File "xx.py", line 8, in
TypeError: object.__new__() takes no parameters
CPython prints:
OldStyle"
----------------------------------------------
----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jdhardy at gmail.com Mon Oct 1 22:29:59 2012
From: jdhardy at gmail.com (Jeff Hardy)
Date: Mon, 1 Oct 2012 13:29:59 -0700
Subject: [Ironpython-users] Iron Python Support for CPython 3.1.5
In-Reply-To:
References:
Message-ID:
Python 3 support is planned, but no one currently has the time to work on it.
- Jeff
On Fri, Sep 28, 2012 at 1:40 AM, Douglas, Peter
wrote:
>
> Hello.
>
> Is there a plan or release scheduled to support CPython 3.1.5 in IronPython?
>
> Regards
> Peter
>
>
>
> Notice: This e-mail is intended solely for use of the individual or entity
> to which it is
> addressed and may contain information that is proprietary, privileged,
> company confidential
> and/or exempt from disclosure under applicable law. If the reader is not the
> intended
> recipient or agent responsible for delivering the message to the intended
> recipient, you are
> hereby notified that any dissemination, distribution or copying of this
> communication is
> strictly prohibited. If this communication has been transmitted from a U.S.
> location it may
> also contain data subject to the International Traffic in Arms Regulations
> or U.S. Export
> Administration Regulations and cannot be disseminated, distributed or copied
> to foreign
> nationals, residing in the U.S. or abroad, without the prior approval of the
> U.S. Department
> of State or appropriate export licensing authority. If you have received
> this communication
> in error, please notify the sender by reply e-mail or collect telephone call
> and delete or
> destroy all copies of this e-mail message, any physical copies made of this
> e-mail message
> and/or any file attachment(s).
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
From ade.canit at gmail.com Tue Oct 2 00:25:06 2012
From: ade.canit at gmail.com (Andrew Evans)
Date: Mon, 1 Oct 2012 15:25:06 -0700
Subject: [Ironpython-users] Hello IronPython and anyone using VST.net?
Message-ID:
Hello my name is Andrew. Some what new to .net and IronPython but I have
programmed lots with Python and a bit of WinAPI. Just wondering if anyone
has built anything with VST.net either in C# or IronPython and can shed a
bit of light to the API. So I can write my own VST software in IronPython
*cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jdhardy at gmail.com Wed Oct 3 07:51:09 2012
From: jdhardy at gmail.com (Jeff Hardy)
Date: Tue, 2 Oct 2012 22:51:09 -0700
Subject: [Ironpython-users] Hello IronPython and anyone using VST.net?
In-Reply-To:
References:
Message-ID:
I don't know about using VST, but creating plugins with IronPython
isn't too bad, if a bit tedious.
The basic idea is that you create a C# plugin that hosts IronPython,
loads your Python code, and calls the necessary methods. This usually
looks something like (not VST-specific, obviously, but the general
pattern):
-- MyPlugin.cs
class MyPlugin : IPlugin {
dynamic plugin;
public MyPlugin() {
this.engine = Python.CreateEngine();
this.scope = this.engine.ExecuteFile('MyPlugin.py');
this.plugin = this.scope.GetVariable("MyPlugin")();
}
public void Foo() {
this.plugin.Foo();
}
public int Bar(int n) {
return this.plugin.Bar(n);
}
}
-- MyPlugin.py
class MyPlugin(object):
def Foo(self):
pass
def Bar(self, n):
return n + 1
There's a couple of pieces I left out but that's the gist of it. There
will be some improvements to make this much, much simpler in 2.7.4,
but I wouldn't hold your breath waiting for it - I'm thinking early
next year.
- Jeff
On Mon, Oct 1, 2012 at 3:25 PM, Andrew Evans wrote:
> Hello my name is Andrew. Some what new to .net and IronPython but I have
> programmed lots with Python and a bit of WinAPI. Just wondering if anyone
> has built anything with VST.net either in C# or IronPython and can shed a
> bit of light to the API. So I can write my own VST software in IronPython
>
> *cheers
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
From no_reply at codeplex.com Sat Oct 6 17:31:24 2012
From: no_reply at codeplex.com (no_reply at codeplex.com)
Date: 6 Oct 2012 08:31:24 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 10/5/2012
Message-ID:
Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New issue] Encoding Problems (Unable to translate bytes...)
----------------------------------------------
ISSUES
1. [New issue] Encoding Problems (Unable to translate bytes...)
http://ironpython.codeplex.com/workitem/33204
User wulfrraem has proposed the issue:
"Hi,
I'm working with a combination of IronPython and jinja2 but keep getting encoding problems from time to time when outputting special characters like '?' or returning such from python methods into jinja context.
For example the template:
{%- set test= '?' %}
{{ test }}
Can produce exceptions (System.Text.DecoderFallbackException) with the message 'Unable to translate bytes [E4] at index 0 from specified code page to Unicode.'
Adding a space character to the end of the second line can bypass this in some cases but this approach can't be used in larger templaes with a structure that changes depending on inputted data.
I guess that these errors stem from the IronPython part because the error messages are C#-Error messages.
Has someone any ideas about this or can give me a hint what I am doing wrong?"
----------------------------------------------
----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From fernandez_dan2 at hotmail.com Sun Oct 7 01:18:18 2012
From: fernandez_dan2 at hotmail.com (Daniel Fernandez)
Date: Sat, 6 Oct 2012 16:18:18 -0700
Subject: [Ironpython-users] WPF can't locate Resource File
Message-ID:
Hi, I'm having a problem with trying to find a xaml resource file. I am using the PyWpfSample as my starting point but I added a resource. I have tried various ways to reference ResourceDictionary>
and The only way I could get it to work is to put the full file path. I have the xaml resources in the same location as my python scripts and main xaml file. I'm not sure if there is another way to reference a resource xaml file. Thanks. Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From no_reply at codeplex.com Fri Oct 12 20:04:26 2012
From: no_reply at codeplex.com (no_reply at codeplex.com)
Date: 12 Oct 2012 11:04:26 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 10/11/2012
Message-ID:
Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New comment] Encoding Problems (Unable to translate bytes...)
----------------------------------------------
ISSUES
1. [New comment] Encoding Problems (Unable to translate bytes...)
http://ironpython.codeplex.com/workitem/33204
User Storminator16 has commented on the issue:
"http://ironpython.codeplex.com/workitem/29505
Related, and it's a old issue. As Jeff Hardy pointed out, replace to_string = unicode with to_string = lambda x: unicode(x) near line 28 of runtime.py in jinja2."
----------------------------------------------
----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From no_reply at codeplex.com Sat Oct 13 17:59:11 2012
From: no_reply at codeplex.com (no_reply at codeplex.com)
Date: 13 Oct 2012 08:59:11 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 10/12/2012
Message-ID:
Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New issue] docutils
----------------------------------------------
ISSUES
1. [New issue] docutils
http://ironpython.codeplex.com/workitem/33218
User cperras has proposed the issue:
"Anyone know if docutils runs under IronPython?
I've been trying, but I get a stack-overflow exception (at least least with the html writer). This occurs if I try to use the API with C# or run rst2html.py directly with ipy.
I'm new to IronPython... I tried installing the source to track down the issue(s), but it throws a "not a zip file" exception whenever I try an import."
----------------------------------------------
----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From no_reply at codeplex.com Sun Oct 14 13:07:24 2012
From: no_reply at codeplex.com (no_reply at codeplex.com)
Date: 14 Oct 2012 04:07:24 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 10/13/2012
Message-ID:
Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New comment] docutils
2. [New issue] locale.setlocale does not detect/set default user locale
----------------------------------------------
ISSUES
1. [New comment] docutils
http://ironpython.codeplex.com/workitem/33218
User paweljasinski has commented on the issue:
"for the stack-overflow, the following stopped it for me. I was able to generate html from a trivial test file.
--- c:/cygwin/home/rejap/tmp/docutils-0.9.1/docutils/nodes.py 2012-01-19 23:33:02.000000000 +0100
+++ c:/github/IronLanguages/bin/Debug/Lib/site-packages/docutils/nodes.py 2012-10-13 22:32:35.787827900 +0200
@@ -58,9 +58,9 @@
false value.
"""
return True
- if sys.version_info < (3,):
+ if sys.version_info < (3,) and sys.platform != 'cli':
# on 2.x, str(node) will be a byte string with Unicode
# characters > 255 escaped; on 3.x this is no longer necessary
def __str__(self):
return unicode(self).encode('raw_unicode_escape')
probably we should switch further discussion to mailing list
Ironpython-users at python.org
http://mail.python.org/mailman/listinfo/ironpython-users"-----------------
2. [New issue] locale.setlocale does not detect/set default user locale
http://ironpython.codeplex.com/workitem/33220
User paweljasinski has proposed the issue:
"according to locale module documentation, the following:
import locale
locale.setlocale(locale.LC_ALL, '')
should set locale to the default user value ("An empty string specifies the user?s default settings.")
As far as I can tell, in case when all env variables are not set (LANG et al), it should be "C", but it is not.
At the same time when LANG is set to a reasonable value (e.g. en_US.UTF-8) it should respect it.
In both cases the locale is not set as expected.
In addition call to:
locale.getlocale()
throws:
Traceback (most recent call last):
File "", line 1, in
File "c:\github\IronLanguages\External.LCA_RESTRICTED\Languages\IronPython\27\Lib\locale.py", line 515, in getlocale
File "c:\github\IronLanguages\External.LCA_RESTRICTED\Languages\IronPython\27\Lib\locale.py", line 428, in _parse_localename
ValueError: unknown locale:"
----------------------------------------------
----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From no_reply at codeplex.com Mon Oct 15 11:49:16 2012
From: no_reply at codeplex.com (no_reply at codeplex.com)
Date: 15 Oct 2012 02:49:16 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 10/14/2012
Message-ID:
Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New comment] locale.setlocale does not detect/set default user locale
----------------------------------------------
ISSUES
1. [New comment] locale.setlocale does not detect/set default user locale
http://ironpython.codeplex.com/workitem/33220
User paweljasinski has commented on the issue:
"I dig a bit deeper and I am wrong on the LANG thing. It is not obligatory.
It should be fine, as long as it respects user default setting and doesn't trigger exception when locale.getlocale() is called"
----------------------------------------------
----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From m.schaber at 3s-software.com Wed Oct 17 12:08:33 2012
From: m.schaber at 3s-software.com (Markus Schaber)
Date: Wed, 17 Oct 2012 10:08:33 +0000
Subject: [Ironpython-users] Restrict referencing of assemblies in hosted
environment
Message-ID: <727D8E16AE957149B447FE368139F2B50D8D7D84@SERVER10>
Hello,
We're using IronPython as a hosted script engine in our application.
Now, we want to restrict the assemblies a user can reference from its python script,
Currently, we just forbid "import clr", by wrapping the import() method, but this is a bit harsh, and the side-effects are a little bit to strong (e. G. it causes "import minidom.py" to fail...)
However, there seems to be no event or other hook available for AddReference which I could use. It may be possible to add an AssemblyLoading event to the ScriptDomainManager in Microsoft.Scripting.Runtime, which allows to cancel the assembly loading by throwing an exception. Would such a patch be accepted upstream?
An alternative (not-so-elegant) idea is that I just wrap all the AddReference() & Co calls inside the clr module, but there may be a more elegant way.
Isolating Ironpython in its own AppDomain is not an option, as this would require major rework of our Scripting API implementation, and also break backwards compatibility for 3rd party plugins which contribute API for the scripts.
(We don't need a 100% waterproof method - we know that the user can use cTypes, System.Reflection, or whatever to circumvent everything - we just want to restrict the obvious ways to access some APIs we consider to be internal.)
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From no_reply at codeplex.com Wed Oct 17 13:26:23 2012
From: no_reply at codeplex.com (no_reply at codeplex.com)
Date: 17 Oct 2012 04:26:23 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 10/16/2012
Message-ID:
Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New issue] Memory Leak when using AppDomains
----------------------------------------------
ISSUES
1. [New issue] Memory Leak when using AppDomains
http://ironpython.codeplex.com/workitem/33242
User Loupi has proposed the issue:
"Hello,
There is a leak when running the engine in another AppDomain.
I created a very simple program to reproduce that (see attachment).
To create the leak, pass true to the CreateEngine function. That way it will use an AppDomain.
Using TaskManager and other tools you'll see the memory increase, then it will throw an OutOfMemoryException.
Passing it false tells it uses the same AppDomain as the application and will no leak.
Tested with IronPython 2.7.1 and 2.7.3."
----------------------------------------------
----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From rome at Wintellect.com Wed Oct 17 17:00:45 2012
From: rome at Wintellect.com (Keith Rome)
Date: Wed, 17 Oct 2012 15:00:45 +0000
Subject: [Ironpython-users] Restrict referencing of assemblies in
hosted environment
In-Reply-To: <727D8E16AE957149B447FE368139F2B50D8D7D84@SERVER10>
References: <727D8E16AE957149B447FE368139F2B50D8D7D84@SERVER10>
Message-ID: <4C554C3A47C5024ABDE00E94DA17BC4D2CD9C534@BY2PRD0711MB417.namprd07.prod.outlook.com>
Take a look at the PlatformAdaptationLayer class. You can create your own and plug it in to the runtime. This might provide the hooks you are looking for.
In particular, you should be able to override the LoadAssembly() and LoadAssemblyFromPath() methods to block anything that isn't whitelisted for your host environment.
Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS
Wintellect | 770.617.4016 | krome at wintellect.com
www.wintellect.com
From: Ironpython-users [mailto:ironpython-users-bounces+rome=wintellect.com at python.org] On Behalf Of Markus Schaber
Sent: Wednesday, October 17, 2012 6:09 AM
To: Discussion of IronPython
Subject: [Ironpython-users] Restrict referencing of assemblies in hosted environment
Hello,
We're using IronPython as a hosted script engine in our application.
Now, we want to restrict the assemblies a user can reference from its python script,
Currently, we just forbid "import clr", by wrapping the import() method, but this is a bit harsh, and the side-effects are a little bit to strong (e. G. it causes "import minidom.py" to fail...)
However, there seems to be no event or other hook available for AddReference which I could use. It may be possible to add an AssemblyLoading event to the ScriptDomainManager in Microsoft.Scripting.Runtime, which allows to cancel the assembly loading by throwing an exception. Would such a patch be accepted upstream?
An alternative (not-so-elegant) idea is that I just wrap all the AddReference() & Co calls inside the clr module, but there may be a more elegant way.
Isolating Ironpython in its own AppDomain is not an option, as this would require major rework of our Scripting API implementation, and also break backwards compatibility for 3rd party plugins which contribute API for the scripts.
(We don't need a 100% waterproof method - we know that the user can use cTypes, System.Reflection, or whatever to circumvent everything - we just want to restrict the obvious ways to access some APIs we consider to be internal.)
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jdhardy at gmail.com Wed Oct 17 17:52:29 2012
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 17 Oct 2012 08:52:29 -0700
Subject: [Ironpython-users] Restrict referencing of assemblies in hosted
environment
In-Reply-To: <727D8E16AE957149B447FE368139F2B50D8D7D84@SERVER10>
References: <727D8E16AE957149B447FE368139F2B50D8D7D84@SERVER10>
Message-ID:
On Wed, Oct 17, 2012 at 3:08 AM, Markus Schaber
wrote:
> Hello,
> We?re using IronPython as a hosted script engine in our application.
> Now, we want to restrict the assemblies a user can reference from its python
> script,
>
> Currently, we just forbid ?import clr?, by wrapping the import() method, but
> this is a bit harsh, and the side-effects are a little bit to strong (e. G.
> it causes ?import minidom.py? to fail?)
>
I'm pretty sure that importing of CLR classes also goes through
__import__(). So you should be able to blacklist/whitelist whatever
classes you want that way. This doesn't prevent loading the
assemblies, but it does make the classes more difficult to access.
If whatever hook you're using to block `import clr` doesn't fire for
`import System` as well, file an issue. And patch, preferably :).
- Jeff
From m.schaber at 3s-software.com Thu Oct 18 09:44:07 2012
From: m.schaber at 3s-software.com (Markus Schaber)
Date: Thu, 18 Oct 2012 07:44:07 +0000
Subject: [Ironpython-users] Restrict referencing of assemblies in hosted
environment
In-Reply-To:
References: <727D8E16AE957149B447FE368139F2B50D8D7D84@SERVER10>
Message-ID: <727D8E16AE957149B447FE368139F2B50D8D8051@SERVER10>
Hi, Jeff,
> Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> On Wed, Oct 17, 2012 at 3:08 AM, Markus Schaber software.com> wrote:
> > We're using IronPython as a hosted script engine in our application.
>
> > Now, we want to restrict the assemblies a user can reference from its
> > python script,
> >
> > Currently, we just forbid "import clr", by wrapping the import()
> > method, but this is a bit harsh, and the side-effects are a little bit
> to strong (e. G.
> > it causes "import minidom.py" to fail...)
> >
>
> I'm pretty sure that importing of CLR classes also goes through
> __import__(). So you should be able to blacklist/whitelist whatever
> classes you want that way. This doesn't prevent loading the assemblies,
> but it does make the classes more difficult to access.
>
> If whatever hook you're using to block `import clr` doesn't fire for
> `import System` as well, file an issue. And patch, preferably :).
It also fires for "import System".
However, this is a different granularity - our "natural" granularity in our existing framework is assemblies, and __import__() works on python modules and .net namespaces, and sometimes a namespace contains members from different assemblies.
I think I'll go with wrapping all the import methods on the clr module then.
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
From m.schaber at 3s-software.com Thu Oct 18 09:53:46 2012
From: m.schaber at 3s-software.com (Markus Schaber)
Date: Thu, 18 Oct 2012 07:53:46 +0000
Subject: [Ironpython-users] Restrict referencing of assemblies in
hosted environment
In-Reply-To: <4C554C3A47C5024ABDE00E94DA17BC4D2CD9C534@BY2PRD0711MB417.namprd07.prod.outlook.com>
References: <727D8E16AE957149B447FE368139F2B50D8D7D84@SERVER10>
<4C554C3A47C5024ABDE00E94DA17BC4D2CD9C534@BY2PRD0711MB417.namprd07.prod.outlook.com>
Message-ID: <727D8E16AE957149B447FE368139F2B50D8D8081@SERVER10>
Hi, Keith,
Von: Keith Rome [mailto:rome at Wintellect.com]
> Take a look at the PlatformAdaptationLayer class. You can create your own and plug it in to the runtime. This might provide the hooks you are looking for.
> In particular, you should be able to override the LoadAssembly() and LoadAssemblyFromPath() methods to block anything that isn't whitelisted for your host environment.
I did think about that method, but as far as I can see, I won't be able to prevent an AddReference("AssemblyName") for an assembly which is already loaded in the current AppDomain.
I'd be happy to be proved wrong on this, however. :-)
Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS
Wintellect | 770.617.4016 | krome at wintellect.com
www.wintellect.com
From: Ironpython-users [mailto:ironpython-users-bounces+rome=wintellect.com at python.org] On Behalf Of Markus Schaber
Sent: Wednesday, October 17, 2012 6:09 AM
To: Discussion of IronPython
Subject: [Ironpython-users] Restrict referencing of assemblies in hosted environment
Hello,
We're using IronPython as a hosted script engine in our application.
Now, we want to restrict the assemblies a user can reference from its python script,
Currently, we just forbid "import clr", by wrapping the import() method, but this is a bit harsh, and the side-effects are a little bit to strong (e. G. it causes "import minidom.py" to fail...)
However, there seems to be no event or other hook available for AddReference which I could use. It may be possible to add an AssemblyLoading event to the ScriptDomainManager in Microsoft.Scripting.Runtime, which allows to cancel the assembly loading by throwing an exception. Would such a patch be accepted upstream?
An alternative (not-so-elegant) idea is that I just wrap all the AddReference() & Co calls inside the clr module, but there may be a more elegant way.
Isolating Ironpython in its own AppDomain is not an option, as this would require major rework of our Scripting API implementation, and also break backwards compatibility for 3rd party plugins which contribute API for the scripts.
(We don't need a 100% waterproof method - we know that the user can use cTypes, System.Reflection, or whatever to circumvent everything - we just want to restrict the obvious ways to access some APIs we consider to be internal.)
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
From no_reply at codeplex.com Thu Oct 18 13:04:59 2012
From: no_reply at codeplex.com (no_reply at codeplex.com)
Date: 18 Oct 2012 04:04:59 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 10/17/2012
Message-ID:
Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New comment] bool value conversion malfunctions with Iron python libraries
----------------------------------------------
ISSUES
1. [New comment] bool value conversion malfunctions with Iron python libraries
http://ironpython.codeplex.com/workitem/33181
User bhadra has commented on the issue:
"
is compares identity. None is not identical to True or False. So "ip_bool is not True" will evaluate to True and "ip_bool is not False" will evaluate to True. the standard Python function bool evaluates a Boolean expression.
[Reference: http://stackoverflow.com/questions/5119709/python-true-false]
So bool value conversion does not malfunction in IronPython.
I suggest that you close the issue.
"
----------------------------------------------
----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jdhardy at gmail.com Thu Oct 18 17:49:36 2012
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 18 Oct 2012 08:49:36 -0700
Subject: [Ironpython-users] Restrict referencing of assemblies in hosted
environment
In-Reply-To: <727D8E16AE957149B447FE368139F2B50D8D8081@SERVER10>
References: <727D8E16AE957149B447FE368139F2B50D8D7D84@SERVER10>
<4C554C3A47C5024ABDE00E94DA17BC4D2CD9C534@BY2PRD0711MB417.namprd07.prod.outlook.com>
<727D8E16AE957149B447FE368139F2B50D8D8081@SERVER10>
Message-ID:
On Thu, Oct 18, 2012 at 12:53 AM, Markus Schaber
wrote:
> Hi, Keith,
>
> Von: Keith Rome [mailto:rome at Wintellect.com]
>> Take a look at the PlatformAdaptationLayer class. You can create your own and plug it in to the runtime. This might provide the hooks you are looking for.
>
>> In particular, you should be able to override the LoadAssembly() and LoadAssemblyFromPath() methods to block anything that isn't whitelisted for your host environment.
>
> I did think about that method, but as far as I can see, I won't be able to prevent an AddReference("AssemblyName") for an assembly which is already loaded in the current AppDomain.
>
> I'd be happy to be proved wrong on this, however. :-)
I'm pretty sure you're right. I don't have a particular issue with
adding an assembly whitelist/blacklist option, but I don't really have
a use case and thus don't have a feel for what it should look like. If
you have some ideas, please open an issue and jot down your thoughts
on what you'd like the API to look like.
- Jeff
From m.schaber at 3s-software.com Thu Oct 18 17:52:21 2012
From: m.schaber at 3s-software.com (Markus Schaber)
Date: Thu, 18 Oct 2012 15:52:21 +0000
Subject: [Ironpython-users] Commercial Support / Bugfixes for Ironpython
Message-ID: <727D8E16AE957149B447FE368139F2B50D8D83B1@SERVER10>
Hi,
Is it possible to hire some of the IronPython Core developers for bugfixes, or is there commercial support available?
Especially http://ironpython.codeplex.com/workitem/31764 is a major issue for some of our users, they fight with Out of Memory exceptions during automated test runs which fire hundreds of IronPython scripts.
For us, it might be cheaper and faster to pay an expert for this task, than trying to solve it on our own.
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From curt at hagenlocher.org Thu Oct 18 18:01:02 2012
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Thu, 18 Oct 2012 09:01:02 -0700
Subject: [Ironpython-users] Commercial Support / Bugfixes for Ironpython
In-Reply-To: <727D8E16AE957149B447FE368139F2B50D8D83B1@SERVER10>
References: <727D8E16AE957149B447FE368139F2B50D8D83B1@SERVER10>
Message-ID:
This doesn't directly address your question, but as I recall,
DefineDynamicAssembly is only used under very particular circumstances. It
can be avoided most of the time in non-debug usage of IronPython. The only
way to release some of the memory usage forced by DefineDynamicAssembly is
to tear down the AppDomain and create a new one. This is a CLR issue.
Disclaimer: I haven't worked on this code in about three years.
On Thu, Oct 18, 2012 at 8:52 AM, Markus Schaber
wrote:
> Hi,****
>
> ** **
>
> Is it possible to hire some of the IronPython Core developers for
> bugfixes, or is there commercial support available?****
>
> ** **
>
> Especially http://ironpython.codeplex.com/workitem/31764 is a major issue
> for some of our users, they fight with Out of Memory exceptions during
> automated test runs which fire hundreds of IronPython scripts.****
>
> ** **
>
> For us, it might be cheaper and faster to pay an expert for this task,
> than trying to solve it on our own.****
>
> ** **
>
> Best regards
>
> Markus Schaber
> --
> ___________________________****
>
> We software Automation.
>
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax
> +49-831-54031-50
>
> Email: *m.schaber at 3s-software.com* | Web: http://www.3s-software.com
> CoDeSys internet forum: http://forum.3s-software.com
> Download CoDeSys sample projects:
> http://www.3s-software.com/index.shtml?sample_projects
>
> *Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner* | *Trade
> register: Kempten HRB 6186* | *Tax ID No.: DE 167014915** *****
>
> ** **
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From m.schaber at 3s-software.com Thu Oct 18 18:16:04 2012
From: m.schaber at 3s-software.com (Markus Schaber)
Date: Thu, 18 Oct 2012 16:16:04 +0000
Subject: [Ironpython-users] Commercial Support / Bugfixes for Ironpython
In-Reply-To:
References: <727D8E16AE957149B447FE368139F2B50D8D83B1@SERVER10>
Message-ID: <727D8E16AE957149B447FE368139F2B50D8D83FE@SERVER10>
Hi, Curt,
Thank you for your answer. Maybe it is possible to utlilise the Collectible Assemblies introduced with .NET 4.0 (http://msdn.microsoft.com/en-us/library/dd554932%28v=vs.100%29.aspx) - they should be fully GC-able...
We can also live with an explicit "Dispose()"-Method to clean up artifacts of old scripts, if that helps further...
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Von: Curt Hagenlocher [mailto:curt at hagenlocher.org]
Gesendet: Donnerstag, 18. Oktober 2012 18:01
An: Markus Schaber
Cc: Discussion of IronPython
Betreff: Re: [Ironpython-users] Commercial Support / Bugfixes for Ironpython
This doesn't directly address your question, but as I recall, DefineDynamicAssembly is only used under very particular circumstances. It can be avoided most of the time in non-debug usage of IronPython. The only way to release some of the memory usage forced by DefineDynamicAssembly is to tear down the AppDomain and create a new one. This is a CLR issue.
Disclaimer: I haven't worked on this code in about three years.
On Thu, Oct 18, 2012 at 8:52 AM, Markus Schaber > wrote:
Hi,
Is it possible to hire some of the IronPython Core developers for bugfixes, or is there commercial support available?
Especially http://ironpython.codeplex.com/workitem/31764 is a major issue for some of our users, they fight with Out of Memory exceptions during automated test runs which fire hundreds of IronPython scripts.
For us, it might be cheaper and faster to pay an expert for this task, than trying to solve it on our own.
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
_______________________________________________
Ironpython-users mailing list
Ironpython-users at python.org
http://mail.python.org/mailman/listinfo/ironpython-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From curt at hagenlocher.org Thu Oct 18 18:31:33 2012
From: curt at hagenlocher.org (Curt Hagenlocher)
Date: Thu, 18 Oct 2012 09:31:33 -0700
Subject: [Ironpython-users] Commercial Support / Bugfixes for Ironpython
In-Reply-To: <727D8E16AE957149B447FE368139F2B50D8D83FE@SERVER10>
References: <727D8E16AE957149B447FE368139F2B50D8D83B1@SERVER10>
<727D8E16AE957149B447FE368139F2B50D8D83FE@SERVER10>
Message-ID:
I don't want to make it sound like I know more than I do; the discussion on
work item 20399 makes it clear that I don't accurately remember all of the
specifics around this issue. But I do recall that we looked at using
collectible assemblies and decided against it. We were still committed to
supporting .NET 2.0 at the time, so that was one factor. But the real
problem is having a realistic idea of when to stop emitting methods into
assembly 1 and start emitting them into assembly 2. Having small
granularity -- too many assemblies -- is a bad thing (for reasons I no
longer remember). But putting too many methods into a single assembly
increases the chance that the assembly will never be collected because one
of its types are still in use.
Running each independent script in its own AppDomain is painful and may
have performance consequences. But ultimately, it gives you the best
control over resource management.
On Thu, Oct 18, 2012 at 9:16 AM, Markus Schaber
wrote:
> Hi, Curt,****
>
> ** **
>
> Thank you for your answer. Maybe it is possible to utlilise the
> Collectible Assemblies introduced with .NET 4.0 (
> http://msdn.microsoft.com/en-us/library/dd554932%28v=vs.100%29.aspx) ?
> they should be fully GC-able?****
>
> ** **
>
> We can also live with an explicit ?Dispose()?-Method to clean up artifacts
> of old scripts, if that helps further?****
>
> ** **
>
> Best regards
>
> Markus Schaber
> --
> ___________________________****
>
> We software Automation.
>
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax
> +49-831-54031-50
>
> Email: *m.schaber at 3s-software.com* | Web: http://www.3s-software.com
> CoDeSys internet forum: http://forum.3s-software.com
> Download CoDeSys sample projects:
> http://www.3s-software.com/index.shtml?sample_projects
>
> *Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner* | *Trade
> register: Kempten HRB 6186* | *Tax ID No.: DE 167014915** *****
>
> ** **
>
> *Von:* Curt Hagenlocher [mailto:curt at hagenlocher.org]
> *Gesendet:* Donnerstag, 18. Oktober 2012 18:01
> *An:* Markus Schaber
> *Cc:* Discussion of IronPython
> *Betreff:* Re: [Ironpython-users] Commercial Support / Bugfixes for
> Ironpython****
>
> ** **
>
> This doesn't directly address your question, but as I recall,
> DefineDynamicAssembly is only used under very particular circumstances. It
> can be avoided most of the time in non-debug usage of IronPython. The only
> way to release some of the memory usage forced by DefineDynamicAssembly is
> to tear down the AppDomain and create a new one. This is a CLR issue.****
>
> ****
>
> Disclaimer: I haven't worked on this code in about three years.****
>
> On Thu, Oct 18, 2012 at 8:52 AM, Markus Schaber
> wrote:****
>
> Hi,****
>
> ****
>
> Is it possible to hire some of the IronPython Core developers for
> bugfixes, or is there commercial support available?****
>
> ****
>
> Especially http://ironpython.codeplex.com/workitem/31764 is a major issue
> for some of our users, they fight with Out of Memory exceptions during
> automated test runs which fire hundreds of IronPython scripts.****
>
> ****
>
> For us, it might be cheaper and faster to pay an expert for this task,
> than trying to solve it on our own.****
>
> ****
>
> Best regards
>
> Markus Schaber
> --
> ___________________________****
>
> We software Automation.
>
> 3S-Smart Software Solutions GmbH
> Markus Schaber | Developer
> Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax
> +49-831-54031-50
>
> Email: *m.schaber at 3s-software.com* | Web: http://www.3s-software.com
> CoDeSys internet forum: http://forum.3s-software.com
> Download CoDeSys sample projects:
> http://www.3s-software.com/index.shtml?sample_projects
>
> *Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner* | *Trade
> register: Kempten HRB 6186* | *Tax ID No.: DE 167014915** *****
>
> ****
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> http://mail.python.org/mailman/listinfo/ironpython-users****
>
> ** **
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From m.schaber at 3s-software.com Fri Oct 19 11:23:04 2012
From: m.schaber at 3s-software.com (Markus Schaber)
Date: Fri, 19 Oct 2012 09:23:04 +0000
Subject: [Ironpython-users] Commercial Support / Bugfixes for Ironpython
In-Reply-To:
References: <727D8E16AE957149B447FE368139F2B50D8D83B1@SERVER10>
<727D8E16AE957149B447FE368139F2B50D8D83FE@SERVER10>
Message-ID: <727D8E16AE957149B447FE368139F2B50D8D8581@SERVER10>
Hi, Curt,
Von: Curt Hagenlocher [mailto:curt at hagenlocher.org]
> Von: Markus Schaber
> > Von: Curt Hagenlocher [mailto:curt at hagenlocher.org]
> > > On Thu, Oct 18, 2012 at 8:52 AM, Markus Schaber wrote:
> > > > Is it possible to hire some of the IronPython Core developers for bugfixes, or is there commercial support available?
> > > > Especially http://ironpython.codeplex.com/workitem/31764 is a major issue for some of our users, they fight with Out of Memory exceptions during automated test runs which fire hundreds of IronPython scripts.
> > > > For us, it might be cheaper and faster to pay an expert for this task, than trying to solve it on our own.
> > > This doesn't directly address your question, but as I recall, DefineDynamicAssembly is only used under very particular circumstances. It can be avoided most of the time in non-debug usage of IronPython. The only way to release some of the memory usage forced by DefineDynamicAssembly is to tear down the AppDomain and create a new one. This is a CLR issue.
> > > Disclaimer: I haven't worked on this code in about three years.
> > Thank you for your answer. Maybe it is possible to utlilise the Collectible Assemblies introduced with .NET 4.0 (http://msdn.microsoft.com/en-us/library/dd554932%28v=vs.100%29.aspx) - they should be fully GC-able...
> > We can also live with an explicit "Dispose()"-Method to clean up artifacts of old scripts, if that helps further...
> I don't want to make it sound like I know more than I do; the discussion on work item 20399 makes it clear that I don't accurately remember all of the specifics around this issue. But I do recall that we looked at using collectible assemblies and decided against it. We were still committed to supporting .NET 2.0 at the time, so that was one factor. But the real problem is having a realistic idea of when to stop emitting methods into assembly 1 and start emitting them into assembly 2. Having small granularity -- too many assemblies -- is a bad thing (for reasons I no longer remember). But putting too many methods into a single assembly increases the chance that the assembly will never be collected because one of its types are still in use.
> Running each independent script in its own AppDomain is painful and may have performance consequences. But ultimately, it gives you the best control over resource management.
On Thu, Oct 18, 2012 at 9:16 AM, Markus Schaber wrote:
In our case, it would be possible to use one collectible assembly for one ScriptEngine.
Using a separate AppDomain would endanger compatibility with 3rd-party plugins providing functionality to the plugins - they need to update to MarshalByRefObject or serializable objects, and we usually have strict backwards guarantees. But maybe that's the only really workable way. (And maybe we find a way to dynamically create and transparently inject MarshalByRefObject-Wrappers into our official script interfaces.)
Just a total different thought, though:
Right now, we create a different ScriptEngine for most script runs. The reason is that we want to have a clean environment for each script, without any artifacts from the previous script run.
Maybe there is a more lightweight approach to achieve this goal. Is there a way to (re-)create such clean environments using the same script engine? (I hope that this could give us the advantage of re-using the generated code when the same script is re-run, or the same module is re-imported - reducing the leak to a bloat.)
Just using a new ScriptScope seems not to be enough, AFAICS, as - for example - sys.modules needs to be re-set (and the modules contents themselves might have been manipulated by the scripts after importing them).
A clean way to "Reset" an existing ScriptEngine would be at least a partial solution - this way, we still would need several Engines (for scripts triggering other scripts), but we could at least recycle them.
Another idea might be a purely interpreted mode - AFAIR, IronRuby provides such a mode, while IronPython does not...
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
From no_reply at codeplex.com Sat Oct 20 14:14:23 2012
From: no_reply at codeplex.com (no_reply at codeplex.com)
Date: 20 Oct 2012 05:14:23 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 10/19/2012
Message-ID:
Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New issue] IronPython.Modules.PythonSignal Throwing Exception When Importing unittest or signal modules
----------------------------------------------
ISSUES
1. [New issue] IronPython.Modules.PythonSignal Throwing Exception When Importing unittest or signal modules
http://ironpython.codeplex.com/workitem/33261
User Storminator16 has proposed the issue:
"I preface this by saying I've only done the legwork so far from the command-line and I'm running the latest version of Iron Python.
This seems to be sporadic as I'm running IronPython on 2 different boxes, both running Windows 7. On one machine, I'm able to import unittest or signal without any problems, but on the other it will fail. If I un-install IronPython then re-install, it works fine for a short while (within an hour's time) before failing again. However, this only seem to be limited to 32 bit version of IronPython, not the 64 bit version.
For more details, please see this StackOverflow post: http://stackoverflow.com/questions/12922336/ironpython-modules-pythonsignal-throwing-exception-when-importing-unittest-modul/12937841#comment17601484_12937841
Other details of note: On the non-problematic machine and the problem one, I have PTVS 1.5 RC installed. On non-problematic machine, I'm running CPython 2.7 64 bit as my default interpreter, the 32 bit version on the problematic machine. I'm sure it doesn't matter, but I decided to mention them just in case."
----------------------------------------------
----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ivanelsonnunes at gmail.com Sun Oct 21 07:00:59 2012
From: ivanelsonnunes at gmail.com (Ivanelson Nunes)
Date: Sun, 21 Oct 2012 02:00:59 -0300
Subject: [Ironpython-users] Drag and Drop components of WIndows Forms.
In-Reply-To:
References:
Message-ID:
The IronPythonStudio been discontinued?
http://ironpythonstudio.codeplex.com/
Currently there any tool that allows developing Windows Forms applications
in IronPython using drag and drop?
Best Regards!
Ivan - Brazil
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From s.j.dower at gmail.com Sun Oct 21 22:37:12 2012
From: s.j.dower at gmail.com (Steve Dower)
Date: Sun, 21 Oct 2012 13:37:12 -0700
Subject: [Ironpython-users] Drag and Drop components of WIndows Forms.
In-Reply-To:
References:
Message-ID:
IronPython Studio is well out of date. Its spiritual successor is
Python Tools for Visual Studio (http://pytools.codeplex.com/, which I
work on), but unfortunately we don't have designer support for Windows
Forms.
I guess this is due to a lack of demand, so you can create a request
on our issue tracker, but it's unlikely that it will be added unless
somebody contributes a patch for it. (We're happy to help anyone who's
interested in doing this.)
Cheers,
Steve
On Sat, Oct 20, 2012 at 10:00 PM, Ivanelson Nunes
wrote:
> The IronPythonStudio been discontinued?
> http://ironpythonstudio.codeplex.com/
>
> Currently there any tool that allows developing Windows Forms applications
> in IronPython using drag and drop?
>
>
> Best Regards!
>
> Ivan - Brazil
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> http://mail.python.org/mailman/listinfo/ironpython-users
>
From m.schaber at 3s-software.com Tue Oct 23 16:56:20 2012
From: m.schaber at 3s-software.com (Markus Schaber)
Date: Tue, 23 Oct 2012 14:56:20 +0000
Subject: [Ironpython-users] WeakRef'tracker
Message-ID: <727D8E16AE957149B447FE368139F2B50D8E7B5A@SERVER10>
Hi,
What's the purpose of IronPython.Rumtime.WeakRefTracker?
I did run the attached program (which is similar to the example for http://ironpython.codeplex.com/workitem/31764).
After running a bunch of scripts, the program calls GC.Collect() and GC.WaitForPendingFinalizers() several times.
At that moment, the code does not hold any reference to any IronPython or Scripting related objects, so I'd expect everything to be cleaned up by the GC.
Despite that fact, I found out that the program spends several seconds with 100% CPU load after returning from the Main() method. When Breaking it in the Debugger several times, it did always end up in the Finalizer method of the WeakRefTracker, so my guess is that most of those several seconds are spent there.
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Program.cs
URL:
From dinov at microsoft.com Wed Oct 24 00:22:41 2012
From: dinov at microsoft.com (Dino Viehland)
Date: Tue, 23 Oct 2012 22:22:41 +0000
Subject: [Ironpython-users] WeakRef'tracker
In-Reply-To: <727D8E16AE957149B447FE368139F2B50D8E7B5A@SERVER10>
References: <727D8E16AE957149B447FE368139F2B50D8E7B5A@SERVER10>
Message-ID: <081eb050a43a40f1b6bcc25ba94448b6@BLUPR03MB591.namprd03.prod.outlook.com>
Python's weak reference support includes the ability to deliver a callback when the object is finalized. That differs from .NET's weak reference support where at best you can poll the weak reference object to find out if the object has gone away. Luckily in Python objects need to opt-in to support weak reference tracking (for example you can't create a weak reference to an int). So to fully support Python's weak reference semantics we have an interface IWeakReferencable which is implemented on Python objects which support weak references. Weak referencable objects all have an extra field (or somewhere) they can store the WeakRefTracker so it's lifetime matches the objects lifetime. Once the object is eligible for collection the weak ref tracker's will also have no other references so it's finalizer will be run, and any weak ref callbacks can then be delivered.
In general WeakRefTracker's should be created lazily - that is someone should be explicitly creating a weak ref to some object. If there's a lot of weak ref's happening then it's not too surprising that the finalizers could take some while to complete. OTOH there could be something odd going on w/ objects being resurrected and maybe having their finalizers running repeatedly (I don't quite remember what happens with finalizable objects when they're resurrected, so maybe this won't happen). Or maybe they're just not being created lazily in some case now. Or maybe the callback is actually doing a lot of work and that's where the CPU time is going.
From: Ironpython-users [mailto:ironpython-users-bounces+dinov=exchange.microsoft.com at python.org] On Behalf Of Markus Schaber
Sent: Tuesday, October 23, 2012 7:56 AM
To: Discussion of IronPython
Subject: [Ironpython-users] WeakRef'tracker
Hi,
What's the purpose of IronPython.Rumtime.WeakRefTracker?
I did run the attached program (which is similar to the example for http://ironpython.codeplex.com/workitem/31764).
After running a bunch of scripts, the program calls GC.Collect() and GC.WaitForPendingFinalizers() several times.
At that moment, the code does not hold any reference to any IronPython or Scripting related objects, so I'd expect everything to be cleaned up by the GC.
Despite that fact, I found out that the program spends several seconds with 100% CPU load after returning from the Main() method. When Breaking it in the Debugger several times, it did always end up in the Finalizer method of the WeakRefTracker, so my guess is that most of those several seconds are spent there.
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From m.schaber at 3s-software.com Wed Oct 24 09:34:03 2012
From: m.schaber at 3s-software.com (Markus Schaber)
Date: Wed, 24 Oct 2012 07:34:03 +0000
Subject: [Ironpython-users] Meta-Questions (Was: Commercial Support /
Bugfixes for Ironpython)
Message-ID: <727D8E16AE957149B447FE368139F2B50D8E8C3C@SERVER10>
Hi,
Just three Meta-Topics:
Does this list prefer the "Internet"-style (Plain-Text, and the replies interleaved with the quoted paragraphs), or "Outlook"-style (HTML/RTF and TOFU)?
When googling for "IronPython Mailing List", the first hit is http://lists.ironpython.com/listinfo.cgi/users-ironpython.com - but this list seems to be replaced by the new one from python.org since 2011. While I like the fact that the old archives are still online, I'd suggest that you add some explanation and link on that page (maybe in the "About Users" part at the top) which points to the new list at python.org.
And it seems that there is no form of commercial support or contracted development available for IronPython and the DLR right now, correct?
Best regards
Markus Schaber
-
> Von: Curt Hagenlocher [mailto:curt at hagenlocher.org]
> > Von: Markus Schaber
> > > Von: Curt Hagenlocher [mailto:curt at hagenlocher.org]
> > > > On Thu, Oct 18, 2012 at 8:52 AM, Markus Schaber > wrote:
> > > > > Is it possible to hire some of the IronPython Core developers for bugfixes, or is there commercial support available?
> > > > > Especially http://ironpython.codeplex.com/workitem/31764 is a major issue for some of our users, they fight with Out of Memory exceptions during automated test runs which fire hundreds of IronPython scripts.
> > > > > For us, it might be cheaper and faster to pay an expert for this task, than trying to solve it on our own.
> > > > This doesn't directly address your question, but as I recall,
> DefineDynamicAssembly is only used under very particular circumstances. It
> can be avoided most of the time in non-debug usage of IronPython. The only
> way to release some of the memory usage forced by DefineDynamicAssembly is
> to tear down the AppDomain and create a new one. This is a CLR issue.
> > > > Disclaimer: I haven't worked on this code in about three years.
> > > Thank you for your answer. Maybe it is possible to utlilise the
> Collectible Assemblies introduced with .NET 4.0
> (http://msdn.microsoft.com/en-us/library/dd554932%28v=vs.100%29.aspx) -
> they should be fully GC-able...
> > > We can also live with an explicit "Dispose()"-Method to clean up
> artifacts of old scripts, if that helps further...
> > I don't want to make it sound like I know more than I do; the discussion
> on work item 20399 makes it clear that I don't accurately remember all of
> the specifics around this issue. But I do recall that we looked at using
> collectible assemblies and decided against it. We were still committed to
> supporting .NET 2.0 at the time, so that was one factor. But the real
> problem is having a realistic idea of when to stop emitting methods into
> assembly 1 and start emitting them into assembly 2. Having small
> granularity -- too many assemblies -- is a bad thing (for reasons I no
> longer remember). But putting too many methods into a single assembly
> increases the chance that the assembly will never be collected because one
> of its types are still in use.
>
> > Running each independent script in its own AppDomain is painful and may
> have performance consequences. But ultimately, it gives you the best
> control over resource management.
> On Thu, Oct 18, 2012 at 9:16 AM, Markus Schaber
> software.com> wrote:
>
> In our case, it would be possible to use one collectible assembly for one
> ScriptEngine.
>
> Using a separate AppDomain would endanger compatibility with 3rd-party
> plugins providing functionality to the plugins - they need to update to
> MarshalByRefObject or serializable objects, and we usually have strict
> backwards guarantees. But maybe that's the only really workable way. (And
> maybe we find a way to dynamically create and transparently inject
> MarshalByRefObject-Wrappers into our official script interfaces.)
>
> Just a total different thought, though:
>
> Right now, we create a different ScriptEngine for most script runs. The
> reason is that we want to have a clean environment for each script,
> without any artifacts from the previous script run.
>
> Maybe there is a more lightweight approach to achieve this goal. Is there
> a way to (re-)create such clean environments using the same script engine?
> (I hope that this could give us the advantage of re-using the generated
> code when the same script is re-run, or the same module is re-imported -
> reducing the leak to a bloat.)
>
> Just using a new ScriptScope seems not to be enough, AFAICS, as - for
> example - sys.modules needs to be re-set (and the modules contents
> themselves might have been manipulated by the scripts after importing
> them).
>
> A clean way to "Reset" an existing ScriptEngine would be at least a
> partial solution - this way, we still would need several Engines (for
> scripts triggering other scripts), but we could at least recycle them.
>
>
> Another idea might be a purely interpreted mode - AFAIR, IronRuby provides
> such a mode, while IronPython does not...
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jdhardy at gmail.com Wed Oct 24 17:01:07 2012
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 24 Oct 2012 08:01:07 -0700
Subject: [Ironpython-users] Meta-Questions (Was: Commercial Support /
Bugfixes for Ironpython)
In-Reply-To: <727D8E16AE957149B447FE368139F2B50D8E8C3C@SERVER10>
References: <727D8E16AE957149B447FE368139F2B50D8E8C3C@SERVER10>
Message-ID:
On Wed, Oct 24, 2012 at 12:34 AM, Markus Schaber
wrote:
> Hi,
> Just three Meta-Topics:
>
> Does this list prefer the ?Internet?-style (Plain-Text, and the replies
> interleaved with the quoted paragraphs), or ?Outlook?-style (HTML/RTF and
> TOFU)?
Personally, I prefer plain-text, inline replies. The difference in
readability between OSS lists that follow that style vs. MS lists
where everyone uses Outlook are night and day. There is no official
list policy, though.
> When googling for ?IronPython Mailing List?, the first hit is
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com - but this
> list seems to be replaced by the new one from python.org since 2011. While I
> like the fact that the old archives are still online, I?d suggest that you
> add some explanation and link on that page (maybe in the ?About Users? part
> at the top) which points to the new list at python.org.
Good catch. The python.org list contains a complete copy of the
archives as well. Looking at them, the message IDs are the same, so it
should be possible to forward the old URLs as well. The old list
server is run by Jim Hugunin, so I'll ping him and see what the
options are.
> And it seems that there is no form of commercial support or contracted
> development available for IronPython and the DLR right now, correct?
As far as I know, no. The people with the knowledge to maintain it all
have full-time jobs. I would love it if one of the contributors was a
contractor who could pick up jobs like that, but no such luck.
- Jeff
From m.schaber at 3s-software.com Wed Oct 24 17:09:48 2012
From: m.schaber at 3s-software.com (Markus Schaber)
Date: Wed, 24 Oct 2012 15:09:48 +0000
Subject: [Ironpython-users] Meta-Questions (Was: Commercial Support /
Bugfixes for Ironpython)
In-Reply-To:
References: <727D8E16AE957149B447FE368139F2B50D8E8C3C@SERVER10>
Message-ID: <727D8E16AE957149B447FE368139F2B50D8E8D13@SERVER10>
Hi, Jeff,
Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> On Wed, Oct 24, 2012 at 12:34 AM, Markus Schaber wrote:
> > Does this list prefer the "Internet"-style (Plain-Text, and the
> > replies interleaved with the quoted paragraphs), or "Outlook"-style
> > (HTML/RTF and TOFU)?
>
> Personally, I prefer plain-text, inline replies. The difference in
> readability between OSS lists that follow that style vs. MS lists where
> everyone uses Outlook are night and day. There is no official list policy,
> though.
I'll try to stick to that standard, then. :-)
> > When googling for "IronPython Mailing List", the first hit is
> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com - but
> > this list seems to be replaced by the new one from python.org since
> > 2011. While I like the fact that the old archives are still online,
> > I'd suggest that you add some explanation and link on that page (maybe
> > in the "About Users" part at the top) which points to the new list at
> > python.org.
>
> Good catch. The python.org list contains a complete copy of the archives
> as well. Looking at them, the message IDs are the same, so it should be
> possible to forward the old URLs as well. The old list server is run by
> Jim Hugunin, so I'll ping him and see what the options are.
Thanks!
> > And it seems that there is no form of commercial support or contracted
> > development available for IronPython and the DLR right now, correct?
>
> As far as I know, no. The people with the knowledge to maintain it all
> have full-time jobs. I would love it if one of the contributors was a
> contractor who could pick up jobs like that, but no such luck.
Maybe one of the companies currently employing one of those people would accept such contracts?
But it seems the only way to get our problem solved is me digging deep into the depths of IronPython and the DLR.
I don't fear that dragon itself, but we're just afraid that it will need to much time, to be measured in weeks or months instead of days.
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
From jdhardy at gmail.com Wed Oct 24 17:38:14 2012
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 24 Oct 2012 08:38:14 -0700
Subject: [Ironpython-users] Meta-Questions (Was: Commercial Support /
Bugfixes for Ironpython)
In-Reply-To: <727D8E16AE957149B447FE368139F2B50D8E8D13@SERVER10>
References: <727D8E16AE957149B447FE368139F2B50D8E8C3C@SERVER10>
<727D8E16AE957149B447FE368139F2B50D8E8D13@SERVER10>
Message-ID:
On Wed, Oct 24, 2012 at 8:09 AM, Markus Schaber
wrote:
> But it seems the only way to get our problem solved is me digging deep into the depths of IronPython and the DLR.
>
> I don't fear that dragon itself, but we're just afraid that it will need to much time, to be measured in weeks or months instead of days.
This might help getting started:
http://www.aosabook.org/en/ironlang.html. Otherwise, just ask. Dino
knows the most about it, and I'm trying to cobble together what I can.
The best advice I have is to jump in and try to fix something.
- Jeff
From m.schaber at 3s-software.com Wed Oct 24 18:26:37 2012
From: m.schaber at 3s-software.com (Markus Schaber)
Date: Wed, 24 Oct 2012 16:26:37 +0000
Subject: [Ironpython-users] Meta-Questions (Was: Commercial Support /
Bugfixes for Ironpython)
In-Reply-To:
References: <727D8E16AE957149B447FE368139F2B50D8E8C3C@SERVER10>
<727D8E16AE957149B447FE368139F2B50D8E8D13@SERVER10>
Message-ID: <727D8E16AE957149B447FE368139F2B50D8E8D42@SERVER10>
Hi, Jeff,
Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> On Wed, Oct 24, 2012 at 8:09 AM, Markus Schaber software.com> wrote:
> > But it seems the only way to get our problem solved is me digging deep
> > into the depths of IronPython and the DLR.
> >
> > I don't fear that dragon itself, but we're just afraid that it will need
> > to much time, to be measured in weeks or months instead of days.
>
> This might help getting started:
> http://www.aosabook.org/en/ironlang.html. Otherwise, just ask. Dino knows
> the most about it, and I'm trying to cobble together what I can.
> The best advice I have is to jump in and try to fix something.
Thanks for the hint - currently, I'm reading the dlr-overview.pdf.
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
From m.schaber at 3s-software.com Thu Oct 25 11:27:56 2012
From: m.schaber at 3s-software.com (Markus Schaber)
Date: Thu, 25 Oct 2012 09:27:56 +0000
Subject: [Ironpython-users] Analyzing the Memory Leak
Message-ID: <727D8E16AE957149B447FE368139F2B50D8E8FA5@SERVER10>
Hi,
I'm currently trying to analyze the memory leak http://ironpython.codeplex.com/workitem/31764
One thing I found out so far is that sys.settrace (which is called by Python.SetTrace internally) seems to call pyContext.PushTracebackHandler without ever pulling that handler.
I did insert some debug output, and it really seems that we're leaking one PythonTracebackListener instance (which internally references the PythonContext) on the thread static _tracebackListeners stack, which keeps all PythonContext instances which ever set a trace alive forever.
However, it seems this is not the only place where the PythonContexts are kept alive, because I tried to replace the Reference within the PythonTracebackListener with a Weak Reference, and the memory still leaked.
But when just not enabling ScriptTracing, the memory leak is reduced drastically, so I'm sure I'm on the right way to uncover at least one of the culprits.
PS:
One annoying thing is that "ClrProfiler" throws Exceptions when trying to get the memory dumps:
System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.
bei CLRProfiler.LiveObjectTable.InsertObject(UInt64 id, Int32 typeSizeStacktraceIndex, Int32 allocTickIndex, Int32 nowTickIndex, Boolean newAlloc, SampleObjectTable sampleObjectTable) in C:\CLRProfilerHelper\CLRProfiler\Sources\CLRProfiler\ReadNewLog.cs:Zeile 1030.
bei CLRProfiler.ReadNewLog.ReadFile(Int64 startFileOffset, Int64 endFileOffset, ReadLogResult readLogResult, Int32 requestedIndex) in C:\CLRProfilerHelper\CLRProfiler\Sources\CLRProfiler\ReadNewLog.cs:Zeile 2440.
bei CLRProfiler.MainForm.showHeapButton_Click(Object sender, EventArgs e) in C:\CLRProfilerHelper\CLRProfiler\Sources\CLRProfiler\MainForm.cs:Zeile 2874.
Do you know of any other good and free (as in beer) tool for memory debugging?
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
From jdhardy at gmail.com Thu Oct 25 16:39:23 2012
From: jdhardy at gmail.com (Jeff Hardy)
Date: Thu, 25 Oct 2012 07:39:23 -0700
Subject: [Ironpython-users] Analyzing the Memory Leak
In-Reply-To: <727D8E16AE957149B447FE368139F2B50D8E8FA5@SERVER10>
References: <727D8E16AE957149B447FE368139F2B50D8E8FA5@SERVER10>
Message-ID:
On Thu, Oct 25, 2012 at 2:27 AM, Markus Schaber
wrote:
> ... Excellent analysis ...
> Do you know of any other good and free (as in beer) tool for memory debugging?
JetBrains' dotTrace. It's not free, but the IronPython project has an
OSS licence and there's a free trial. Give it a spin and if it works
I'll send you the licence information.
- Jeff
From rome at Wintellect.com Thu Oct 25 16:57:33 2012
From: rome at Wintellect.com (Keith Rome)
Date: Thu, 25 Oct 2012 14:57:33 +0000
Subject: [Ironpython-users] Analyzing the Memory Leak
In-Reply-To:
References: <727D8E16AE957149B447FE368139F2B50D8E8FA5@SERVER10>
Message-ID: <4C554C3A47C5024ABDE00E94DA17BC4D2CDC7CFF@BLUPRD0711MB412.namprd07.prod.outlook.com>
To add another recommendation...
SciTech's Memory Profiler has a 7-day trial (non-consecutive... so you can use it one day a month for 7 months if you want). SciTech is what many people swear by - having used dotTrace, ANTS, and even good 'ole CLR Profiler and low-level heap walking in WinDBG/SoS, I find SciTech to be the most powerful and stable (ANTS tends to be particularly unstable).
http://memprofiler.com/
Keith Rome
Senior Consultant and Architect
MCPD-EAD, MCSD, MCDBA, MCTS-WPF, MCTS-TFS, MCTS-WSS
Wintellect | 770.617.4016 | krome at wintellect.com
www.wintellect.com
-----Original Message-----
From: Ironpython-users [mailto:ironpython-users-bounces+rome=wintellect.com at python.org] On Behalf Of Jeff Hardy
Sent: Thursday, October 25, 2012 10:39 AM
To: Markus Schaber
Cc: Discussion of IronPython
Subject: Re: [Ironpython-users] Analyzing the Memory Leak
On Thu, Oct 25, 2012 at 2:27 AM, Markus Schaber wrote:
> ... Excellent analysis ...
> Do you know of any other good and free (as in beer) tool for memory debugging?
JetBrains' dotTrace. It's not free, but the IronPython project has an OSS licence and there's a free trial. Give it a spin and if it works I'll send you the licence information.
- Jeff
_______________________________________________
Ironpython-users mailing list
Ironpython-users at python.org
http://mail.python.org/mailman/listinfo/ironpython-users
From m.schaber at 3s-software.com Fri Oct 26 08:47:52 2012
From: m.schaber at 3s-software.com (Markus Schaber)
Date: Fri, 26 Oct 2012 06:47:52 +0000
Subject: [Ironpython-users] Analyzing the Memory Leak
In-Reply-To:
References: <727D8E16AE957149B447FE368139F2B50D8E8FA5@SERVER10>
Message-ID: <727D8E16AE957149B447FE368139F2B50D8E910C@SERVER10>
Hi, Jeff,
Von: Jeff Hardy [mailto:jdhardy at gmail.com]
> On Thu, Oct 25, 2012 at 2:27 AM, Markus Schaber
> wrote:
> > ... Excellent analysis ...
>
> > Do you know of any other good and free (as in beer) tool for memory
> debugging?
>
> JetBrains' dotTrace. It's not free, but the IronPython project has an OSS
> licence and there's a free trial. Give it a spin and if it works I'll send
> you the licence information.
At least, it's not crashing. However, it traces some of the leaked objects to
a "Garbage Collector Handle", and it seems it does not record where this
handle was allocated.
However, I now know where the object itself was allocated, and try to step
through the code to find out where that handle is created.
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber at 3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
From no_reply at codeplex.com Sat Oct 27 12:15:11 2012
From: no_reply at codeplex.com (no_reply at codeplex.com)
Date: 27 Oct 2012 03:15:11 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 10/26/2012
Message-ID:
Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New comment] Memory Leak when using AppDomains
2. [New comment] Memory Leak when using AppDomains
----------------------------------------------
ISSUES
1. [New comment] Memory Leak when using AppDomains
http://ironpython.codeplex.com/workitem/33242
User MarkusSchaber has commented on the issue:
"Hello,
It seems you don't unload your AppDomains. You need to explicitly unload it when it is not needed any more.
See http://msdn.microsoft.com/de-de/library/system.appdomain.unload.aspx for more information.
HTH,
Markus"-----------------
2. [New comment] Memory Leak when using AppDomains
http://ironpython.codeplex.com/workitem/33242
User Loupi has commented on the issue:
"Markus,
This really does not explain why memory goes up and up and it's never released ONLY when using an AppDomain. In my opinion, unloading the AppDomain is a band-aid solution that does not solve the real problem at its root. Also, I really do not want to allocate an AppDomain per running script.
I want to use a single ScriptEngine, associated with an AppDomain, that runs multiple scripts. And I think it was designed this way.
Now imagine that i have a single ScriptEngine, running multiple scripts in parallel, each in it's own thread. Continuously. I always need the AppDomain to live in this situation. Monitoring memory to schedule an AppDomain unload looks also very ugly to me.
"
----------------------------------------------
----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From no_reply at codeplex.com Mon Oct 29 14:43:30 2012
From: no_reply at codeplex.com (no_reply at codeplex.com)
Date: 29 Oct 2012 06:43:30 -0700
Subject: [Ironpython-users] IronPython, Daily Digest 10/28/2012
Message-ID:
Hi ironpython,
Here's your Daily Digest of new issues for project "IronPython".
In today's digest:ISSUES
1. [New comment] bool value conversion malfunctions with Iron python libraries
----------------------------------------------
ISSUES
1. [New comment] bool value conversion malfunctions with Iron python libraries
http://ironpython.codeplex.com/workitem/33181
User SriharshaVardhan has commented on the issue:
"If ip_bool is none then I would expect ip_bool.__class__.__name__ not to return the type as class :bool"
----------------------------------------------
----------------------------------------------
You are receiving this email because you subscribed to notifications on CodePlex.
To report a bug, request a feature, or add a comment, visit IronPython Issue Tracker. You can unsubscribe or change your issue notification settings on CodePlex.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jwhitby at gmail.com Wed Oct 31 04:13:14 2012
From: jwhitby at gmail.com (Jared Whitby)
Date: Tue, 30 Oct 2012 23:13:14 -0400
Subject: [Ironpython-users] clrtype.py duplicate type name within an assembly
Message-ID:
Hey guys,****
** **
I've been trying to use IronPython as a scripting solution in a project I
am working on. I am using clrtype.py from the clrtype sample to expose
attributes on methods into c# so I can use reflection to register them with
my application. The first time the script runs, everything works fine. But
I want the users to be able to change the script while the application is
running so I need to load and run the script again. When I try to load and
run the script a second time I get a ArgumentException ?Duplicate type name
within an assembly?.
**
** **
I threw together a little example using part of the Sample.py file that is
included with the crltype sample. The exception gets thrown on the
?scriptSource.Execute(scriptScope);? line the second time through. If I
comment out ?__metaclass__ = clrtype.ClrClass? from Product in sample.py it
runs fine every time. But that disables the clrtype functionality I need.***
*
** **
Any ideas how to get around this? Am I doing something wrong that you can
see?****
** **
I got clrtype.py from the samples download in this link:
http://ironpython.codeplex.com/releases/view/12482****
Here's the code snippet where the script is run
var engine = Python.CreateEngine(); var scriptSource =
engine.CreateScriptSourceFromFile("C:\\Sample\\Python\\Sample.py"); var
scriptScope = engine.CreateScope(); scriptSource.Execute(scriptScope); var
myClassVar = scriptScope.GetVariable("Product"); var myClass =
myClassVar("Name", 10, 2); var result = myClass.calc_total();
System.ArgumentException was unhandled
**
Message=Duplicate type name within an assembly.****
Source=Microsoft.Dynamic****
StackTrace:****
at
Microsoft.Scripting.Interpreter.NewInstruction.Run(InterpretedFrame frame)**
**
at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame
frame)****
at
Microsoft.Scripting.Interpreter.LightLambda.Run7[T0,T1,T2,T3,T4,T5,T6,TRet](T0
arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6)****
at
System.Dynamic.UpdateDelegates.UpdateAndExecute6[T0,T1,T2,T3,T4,T5,TRet](CallSite
site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5)****
at
IronPython.Runtime.Types.UserInstanceCreator.CreateInstance(CodeContext
context, Object arg0, Object arg1, Object arg2)****
at IronPython.Runtime.Types.PythonType.CreateInstance(CodeContext
context, Object arg0, Object arg1, Object arg2)****
at IronPython.Runtime.Types.PythonType.__new__(CodeContext context,
PythonType cls, String name, PythonTuple bases, PythonDictionary dict,
String selfNames)****
at IronPython.Runtime.Types.PythonType.__new__(CodeContext context,
PythonType cls, String name, PythonTuple bases, PythonDictionary dict)****
at
Microsoft.Scripting.Interpreter.FuncCallInstruction`6.Run(InterpretedFrame
frame)****
at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame
frame)****
at
Microsoft.Scripting.Interpreter.LightLambda.Run6[T0,T1,T2,T3,T4,T5,TRet](T0
arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5)****
at
System.Dynamic.UpdateDelegates.UpdateAndExecute5[T0,T1,T2,T3,T4,TRet](CallSite
site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4)****
at
Microsoft.Scripting.Interpreter.FuncCallInstruction`8.Run(InterpretedFrame
frame)****
at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame
frame)****
at
Microsoft.Scripting.Interpreter.LightLambda.Run6[T0,T1,T2,T3,T4,T5,TRet](T0
arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5)****
at IronPython.Runtime.Operations.PythonOps.MakeClass(CodeContext
context, String name, Object[] bases, String selfNames, PythonDictionary
vars)****
at IronPython.Runtime.Operations.PythonOps.MakeClass(FunctionCode
funcCode, Func`2 body, CodeContext parentContext, String name, Object[]
bases, String selfNames)****
at
Microsoft.Scripting.Interpreter.FuncCallInstruction`7.Run(InterpretedFrame
frame)****
at Microsoft.Scripting.Interpreter.Interpreter.Run(InterpretedFrame
frame)****
at Microsoft.Scripting.Interpreter.LightLambda.Run2[T0,T1,TRet](T0
arg0, T1 arg1)****
at IronPython.Compiler.PythonScriptCode.RunWorker(CodeContext ctx)***
*
at IronPython.Compiler.PythonScriptCode.Run(Scope scope)****
at IronPython.Compiler.RuntimeScriptCode.InvokeTarget(Scope scope)***
*
at IronPython.Compiler.RuntimeScriptCode.Run(Scope scope)****
at Microsoft.Scripting.SourceUnit.Execute(Scope scope, ErrorSink
errorSink)****
at Microsoft.Scripting.SourceUnit.Execute(Scope scope)****
at Microsoft.Scripting.Hosting.ScriptSource.Execute(ScriptScope
scope)****
at Commands.TempScriptingComand.Execute(Object lSelectedItem, Task
lTask) in C:\dev\Commands\TempScriptingComand.cs:line 152****
at
MS.Internal.Commands.CommandHelpers.CriticalExecuteCommandSource(ICommandSource
commandSource, Boolean userInitiated)****
at System.Windows.Controls.Primitives.ButtonBase.OnClick()****
at System.Windows.Controls.Button.OnClick()****
at
System.Windows.Controls.Primitives.ButtonBase.OnMouseLeftButtonUp(MouseButtonEventArgs
e)****
at System.Windows.UIElement.OnMouseLeftButtonUpThunk(Object sender,
MouseButtonEventArgs e)****
at
System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate
genericHandler, Object genericTarget)****
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler,
Object target)****
at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object target,
RoutedEventArgs routedEventArgs)****
at System.Windows.EventRoute.InvokeHandlersImpl(Object source,
RoutedEventArgs args, Boolean reRaised)****
at System.Windows.UIElement.ReRaiseEventAs(DependencyObject sender,
RoutedEventArgs args, RoutedEvent newEvent)****
at System.Windows.UIElement.OnMouseUpThunk(Object sender,
MouseButtonEventArgs e)****
at
System.Windows.Input.MouseButtonEventArgs.InvokeEventHandler(Delegate
genericHandler, Object genericTarget)****
at System.Windows.RoutedEventArgs.InvokeHandler(Delegate handler,
Object target)****
at System.Windows.RoutedEventHandlerInfo.InvokeHandler(Object
target, RoutedEventArgs routedEventArgs)****
at System.Windows.EventRoute.InvokeHandlersImpl(Object source,
RoutedEventArgs args, Boolean reRaised)****
at System.Windows.UIElement.RaiseEventImpl(DependencyObject sender,
RoutedEventArgs args)****
at System.Windows.UIElement.RaiseTrustedEvent(RoutedEventArgs args)**
**
at System.Windows.UIElement.RaiseEvent(RoutedEventArgs args, Boolean
trusted)****
at System.Windows.Input.InputManager.ProcessStagingArea()****
at System.Windows.Input.InputManager.ProcessInput(InputEventArgs
input)****
at System.Windows.Input.InputProviderSite.ReportInput(InputReport
inputReport)****
at System.Windows.Interop.HwndMouseInputProvider.ReportInput(IntPtr
hwnd, InputMode mode, Int32 timestamp, RawMouseActions actions, Int32 x,
Int32 y, Int32 wheel)****
at System.Windows.Interop.HwndMouseInputProvider.FilterMessage(IntPtr
hwnd, WindowMessage msg, IntPtr wParam, IntPtr lParam, Boolean& handled)****
at System.Windows.Interop.HwndSource.InputFilterMessage(IntPtr hwnd,
Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)****
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr
wParam, IntPtr lParam, Boolean& handled)****
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)****
at
System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate
callback, Object args, Int32 numArgs)****
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object
source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)*
***
at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority
priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)****
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg,
IntPtr wParam, IntPtr lParam)****
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)****
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame
frame)****
at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame
frame)****
at System.Windows.Application.RunDispatcher(Object ignore)****
at System.Windows.Application.RunInternal(Window window)****
at System.Windows.Application.Run(Window window)****
at System.Windows.Application.Run()****
** **
Here?s the Sample.py file I?m using.**
** **
import clr****
import clrtype****
import System****
from System.Reflection import BindingFlags****
** **
class IProduct(object):****
__metaclass__ = clrtype.ClrInterface****
** **
_clrnamespace = "IronPython.Samples.ClrType" ****
** **
@property****
@clrtype.accepts()****
@clrtype.returns(str)****
def Name(self): raise RuntimeError("this should not get called")****
****
@property****
@clrtype.accepts()****
@clrtype.returns(float)****
def Cost(self): raise RuntimeError("this should not get called")****
****
@clrtype.accepts()****
@clrtype.returns(bool)****
def IsAvailable(self): raise RuntimeError("this should not get called")*
***
** **
class Product(IProduct):****
__metaclass__ = clrtype.ClrClass****
****
_clrnamespace = "IronPython.Samples.ClrType" ****
****
_clrfields = {****
"name":str,****
"cost":float,****
"_quantity":int****
}****
****
CLSCompliant = clrtype.attribute(System.CLSCompliantAttribute)****
clr.AddReference("System.Xml")****
XmlRoot = clrtype.attribute(System.Xml.Serialization.XmlRootAttribute)**
**
****
_clrclassattribs = [****
# Use System.Attribute subtype directly for custom attributes
without arguments****
System.ObsoleteAttribute,****
# Use clrtype.attribute for custom attributes with arguments
(either positional, named, or both)****
CLSCompliant(False),****
XmlRoot("product", Namespace="www.contoso.com")****
]****
** **
def __init__(self, name, cost, quantity):****
self.name = name****
self.cost = cost****
self._quantity = quantity****
** **
# IProduct methods ****
def Name(self): return self.name****
def Cost(self): return self.cost****
def IsAvailable(self): return self.quantity != 0****
** **
@property****
@clrtype.accepts()****
@clrtype.returns(int)****
def quantity(self): return self._quantity****
****
@quantity.setter****
@clrtype.accepts(int)****
@clrtype.returns()****
def quantity(self, value): self._quantity = value****
** **
@clrtype.accepts(float)****
@clrtype.returns(float)****
def calc_total(self, discount = 0.0):****
return (self.cost - discount) * self.quantity****
** **
Thanks,****
** **
Jared
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jdhardy at gmail.com Wed Oct 31 16:53:26 2012
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 31 Oct 2012 08:53:26 -0700
Subject: [Ironpython-users] clrtype.py duplicate type name within an
assembly
In-Reply-To:
References:
Message-ID:
On Tue, Oct 30, 2012 at 8:13 PM, Jared Whitby wrote:
> Hey guys,
>
> I've been trying to use IronPython as a scripting solution in a project I am
> working on. I am using clrtype.py from the clrtype sample to expose
> attributes on methods into c# so I can use reflection to register them with
> my application. The first time the script runs, everything works fine. But I
> want the users to be able to change the script while the application is
> running so I need to load and run the script again. When I try to load and
> run the script a second time I get a ArgumentException ?Duplicate type name
> within an assembly?.
>
> ...
>
> Any ideas how to get around this? Am I doing something wrong that you can
> see?
It's a limitation of how IronPython generates code (and by extension,
clrtype.py). When it runs, it creates a dynamic assembly and creates
types in it, but it only does this once per process. Your use case is
interesting, and one that I don't think was ever considered - it was
assumed that the scripts (using clrtypes) would not be reloaded. One
potential issue is that I believe dynamic assemblies cannot be garbage
collected, although this may have changed in newer version of the CLR
(I can't keep track anymore!).
Would it be possible to not use reflection? Or does your system
require it for other reasons? You could potentially use the DLR APIs
to query the objects and then register them, which would avoid the use
of clrtypes at all.
- Jeff
From jdhardy at gmail.com Wed Oct 31 18:12:30 2012
From: jdhardy at gmail.com (Jeff Hardy)
Date: Wed, 31 Oct 2012 10:12:30 -0700
Subject: [Ironpython-users] Integrated Typed Class Generation
Message-ID:
Jared's email reminded me that I needed to get some feedback on how I plan
to integrate clrtypes.py into IronPython. Currently, most of what's in
clrtypes.py will move into the clr module, but a few pieces will be
renamed. Loosely, it will look like:
clr.assembly_attribute(AssemblyVersionAttribute("1.0.0.0"))
class Foo(object):
__metaclass__ = clr.TypedClass
__clr_namespace__ = 'MyFoo'
__clr_attributes__ = [
CLSCompliantAttribute(False)
]
def __init__(self):
self._bar = 0
@clr.property(int) # (type, virtual=True)
def bar(self): return self._bar
@bar.setter
def bar(self, value): self._bar = value
@ObsoleteAttribute
@clr.method(int, [int], virtual=False) # (return, args, virtual=True)
def frob(self, n):
return n*n
@clr.staticmethod(int, [int]) # (return, args)
def static_frob(n):
return n*n
Methods (and properties) are virtual by default, in keeping with normal
Python expectations. I'm not currently planning any visibility control
(public, private, etc.), either, but it's not too difficult to do if
requested.
Interfaces will look similar, except their metaclass will be
clr.TypedInterface (but they may not make the first release). I have no
plans for structs right now.
Fields are another thing that probably won't make v1, simply because I
don't see a really good use case for them (unlike properties). Ditto
overloaded methods (that will require a lot of work, but I think it's
possible).
I keep pondering whether I want to muck with namespaces to drop the
'Attribute' from attribute type names. Right now, I'm leaning against it.
The second part of this is improvements to pyc.py, which will now become
ipyc.exe (literally, in fact - the build process uses pyc.py to compile
*itself* into ipyc.exe). This will allow the creation of assemblies that
expose actual typed CLR classes, for use as plugins. For example, I'm also
working on some MSBuild Tasks to run ipyc, which are written in Python and
compiled with ipyc. Any sort of plugin should now be directly possible with
IronPython.
Finally, the new ipyc will gain the ability to target multiple platforms.
WinRT, WP8, iOS, and Android all require (some) classes to be generated
ahead of time, which ipyc will take care of, while also fixing up assembly
references/versions/etc. so that the various runtimes will load the
generated assemblies. For example, Android requires running the
mandroid.exe tool to generate wrappers for Android UI classes, and
WinRT/WP8 have no ability to generate classes at runtime *at all* (don't
get me started on that one...). This is finicky, as you might imagine, but
entirely doable. The real key is that IronPython's generated code really
only depends on CLR2 features, so only some metadata needs to be changed
and some namespaces fixed up.
All of this is a long way of saying that 2.7.4 is going to have some crazy
cool stuff in it, but it's taking a while to get it put together. If you're
interested in a preview, my static-pyc branch (
https://github.com/jdhardy/ironpython/tree/static-pyc) has the current
working version. I'd like to put out an Alpha by the end of November, but I
make no promises. :)
- Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From dinov at microsoft.com Wed Oct 31 23:09:41 2012
From: dinov at microsoft.com (Dino Viehland)
Date: Wed, 31 Oct 2012 22:09:41 +0000
Subject: [Ironpython-users] ANN: Python Tools for Visual Studio 1.5
Message-ID: <66535cac8282494cb7dcddea5f726379@BY2PR03MB596.namprd03.prod.outlook.com>
We're pleased to announce the release of Python Tools for Visual Studio 1.5 RTM - http://pytools.codeplex.com/releases/view/82132. Python Tools for Visual Studio (PTVS) is an open-source plug-in for Visual Studio which supports programming with the Python language. PTVS supports a broad range of features including CPython/IronPython, Edit/Intellisense/Debug/Profile, Cloud, HPC, IPython, etc. support.
For a quick overview of the general IDE experience, please see http://www.youtube.com/watch?v=7CoGsSlrxKk
There are a number of exciting improvement in this release compared to 1.1, all based on your feedback & suggestions. Here's a summary:
IDE:
* VS2012 support
* Django Project, Edit, Intellisense, Template debugging support: - YT: http://www.youtube.com/watch?v=UsLti4KlgAY
* A Live Debug REPL - YT: http://www.youtube.com/watch?v=erNx2NLu-t4&hd=1
* "Parallel Stack" View and "Parallel Watch" windows for threaded code support - YT: http://www.youtube.com/watch?v=WRs4r-cQfjE
* Project load time improvements
* PyKinect: Kinect SDK 1.5 support
* New "New Project from Existing Code!"
* Improved Intellisense (iterator, PyQt, ...)
* Python 3.3 language support
Cloud:
* Python is now a 1st class language on Azure! See: https://www.windowsazure.com/en-us/develop/python/
* Azure Python Client Libraries for Windows, MacOS and Linux (not a typo). See https://github.com/WindowsAzure/azure-sdk-for-python ;
o On PyPI: http://pypi.python.org/pypi/azure/
o On GitHub: https://github.com/WindowsAzure/azure-sdk-for-python
* New in 1.5 RTM: Azure Python Client Lib support for System Management API's. - YT: http://www.youtube.com/watch?v=nDvqNP_Ja5s
* IPython on Azure: A Python IDE in the browser, backed by a Windows or Linux VM. See: https://www.windowsazure.com/en-us/develop/python/tutorials/ipython-notebook/
* Azure: new WFastCGI for Azure/IIS
* Azure "Web Sites" Python Framework support: Django, Flask, Bottle, Web2Py, ... support <>
There were over 100 fixes/improvements in this release compared to 1.1. Here's a link to the list of changes: http://bit.ly/PTVS15RTMBugs
We'd like to thank the following people who took the time to report the issues and feedback for this release (in reverse chronological order):
RC: Tmaslach, odwalla, jrade, michiya, timeisparallax, tachiorz, sourbox, tramsay, bahrep, lqbest127, hyh, mrpy, boomer_74, BigFreakinGobot, AngeloBast, ajp, mahpour, cecilphillip, dhabersat.
Beta: ajp, Anna0311, golubdr, hjyh, hyh, mahpour, tramsay, and zooba.
Alpha: Anna0311, golubdr, hjyh, tramsay, zooba.
Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: