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: