[IronPython] Control event ids
Hi List
import clr
clr.AddReference('System.Windows.Forms')
from System.Windows.Forms import TabControl
t = TabControl()
t.MouseDown == t.MouseDown
False
t.MouseDown is t.MouseDown
False
This behaviour makes it extremely cumbersome to detach from events (some
events, anyway; I'm pretty certain that I've seen events which don't
exhibit this behaviour, but I can't remember what they are).
Is this an IronPython bug, or have I got a broken mental model of what
should be happening?
Cheers
William
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Control event ids
On Thu, Apr 30, 2009 at 4:02 AM, William Reade will...@resolversystems.com wrote: Is this an IronPython bug, or have I got a broken mental model of what should be happening? CLR events are not objects but endpoints, so you can't really do objectey things with them. This behaviour makes it extremely cumbersome to detach from events (some events, anyway; I'm pretty certain that I've seen events which don't exhibit this behaviour, but I can't remember what they are). An example of this would be useful. -- Curt Hagenlocher c...@hagenlocher.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Crash with Action and reflection question
Hello all, The following seems to crash the IronPython 2.0.1 interpreter: from System import Action Action(lambda: foo) Obviously it's invalid - but it kills the interpreter rather than raising an exception. I'm doing some introspection and I'd like to work out the return types of methods of .NET objects. One route would be to parse the docstring. :-) Another way would be to get the MethodInfo. For an arbitrary .NET type from inside IronPython how do I get a System.Type instance representing the type? (I'd quite like an answer to that question - but if you also have a suggestion as to a better way that would be great as well...) Thanks Michael -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Crash with Action and reflection question
On Thu, Apr 30, 2009 at 6:09 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: The following seems to crash the IronPython 2.0.1 interpreter: from System import Action Action(lambda: foo) Obviously it's invalid - but it kills the interpreter rather than raising an exception. It's been fixed for 2.6 (http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=19133). If it's a fix that you want for the 2.0 branch, feel free to open another item on Codeplex :). Another way would be to get the MethodInfo. For an arbitrary .NET type from inside IronPython how do I get a System.Type instance representing the type? You mean like this? from System.Collections.Generic import List runtimeType = clr.GetClrType(List) -- Curt Hagenlocher c...@hagenlocher.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Crash with Action and reflection question
Curt Hagenlocher wrote: On Thu, Apr 30, 2009 at 6:09 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: The following seems to crash the IronPython 2.0.1 interpreter: from System import Action Action(lambda: foo) Obviously it's invalid - but it kills the interpreter rather than raising an exception. It's been fixed for 2.6 (http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=19133). If it's a fix that you want for the 2.0 branch, feel free to open another item on Codeplex :). Thanks - not massively worried about. Another way would be to get the MethodInfo. For an arbitrary .NET type from inside IronPython how do I get a System.Type instance representing the type? You mean like this? from System.Collections.Generic import List runtimeType = clr.GetClrType(List) Exactly! Thank you. I need you on IM so I can bug you with these questions more easily... :-) Michael -- Curt Hagenlocher c...@hagenlocher.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] [wingide-users] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator)
Hello all, Another update to the PI file generator for .NET objects. This one adds return type annotations for methods. It means that if you do something like: from System import Guid g = Guid.NewGuid() Wing knowsthat g is a Guid and provides the correct auto-complete members for it. This is *great*. See previous instructions on how to use the script. It now takes quite a *long* time to generate all 90 PI files. :-) There is a caveat with this currently: Many methods return types that are defined in other namespaces (especially types defined in System). Because those types are in another PI file, Wing doesn't recognise them. I'll work out how to fix this (from System import * at the top of each PI file might catch most cases). Secondly return types can currently return things like Array[int]() the indexing will cause Wing to effectively ignore the return type - so I should change this to Array(). Still - getting there step-by-step and this is already enormously useful to me. I'm currently using a truly horrible regular expression to pull the return type out of the docstring... I'll write this all up into a proper 'HOWTO: IronPython in Wing' once I have time. All the best, Michael Michael Foord wrote: Hello all, Attached is an updated script for generating PI files to provide autocomplete on standard .NET objects. It now handles all the standard .NET member types (including static properties, enumeration fields, indexers, events and so on). It also recurses into sub-namespaces generating new pi-files for all of them. This script is hardcoded to add references to, and then generate PI files for: System System.Data System.Drawing System.Windows.Forms It generates 90 pi files (90 namespaces) taking up 24mb! The autocomplete it provides is awesome though. :-) I had to do a fair bit of violence to the standard generate_pi.py script so I *doubt* it is desirable to merge it back in. Obviously very happy for this to be included with Wing if you want, or merged if you think it is worth it. Is it ok for me to offer this for download from my site? If I make further changes I will email this list. The big thing to add is the return type for methods. Is it possible to specify return types for properties? (Currently any attribute without an obvious parallel in Python I have turned into a property in the PI files). The only real caveat with the current script (that I am aware of - bug reports and contributions welcomed) is that None is a common enumeration field member. This is invalid syntax in Python, so I rename these to None_. There are quite a few minor changes sprinkled through the code - plus the __main__ part of the script is very different. I have tried to mark changes with a # CHANGE: comment, but it should be relatively amenable to diffing anyway... For reference I was using IronPython 2.0.1, with .NET 3.5 installed and Wing 3.2beta 1. All the best, Michael Foord Michael Foord wrote: Hello all, I've created a modified version of the 'generate_pi.py' which generates the interface files for .NET libraries. It is attached. At the moment it generates PI files for the following assemblies / namespaces (hardwired at the bottom of the code): System System.Data System.Drawing System.Windows.Forms To run it, create a new directory and add this to the 'Interface File Path' (File menu - Preferences - Source Analysis - Advanced - Insert). Then from the command line switch to this directory (if you are on Vista you will need to run cmd with admin privileges due to a defect explained below). Execute the command: ipy generate_pi_for_net.py This generates the pi files. It doesn't work *as well* on 64 bit windows because the .NET XML help files (or whatever they are called) are in a different location so the docstrings are not always available - which is why I am not just distributing the pi files yet. The script doesn't yet understand static properties on classes - so it actually *fetches* static properties rather than looking at the descriptor (which is available in the class __dict__ so should be easy to fix). This is what causes inadvertent registry lookups etc and therefore requires admin privileges. It doesn't yet understand multiple overloads. This may require a change to Wing or may not matter. It isn't yet able to do anything with the information about return types - which would allow Wing to know the type of objects returned by methods. This may be easy to add? It is late so I am going to bed. At some point I will explain the simple changes I had to make to the standard generate_pi.py script (although they are mostly straightforward). I will also do further work on it as it will be very useful to me... All the best, Michael _ Wing IDE users list
[IronPython] Is Silverlight 3 beta supported in Ironpython yet?
Does Ironpython support Silverlight 3 beta yet? /Kristian ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Crash with Action and reflection question
-Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Thursday, April 30, 2009 3:19 PM To: Discussion of IronPython Subject: Re: [IronPython] Crash with Action and reflection question Another way would be to get the MethodInfo. For an arbitrary .NET type from inside IronPython how do I get a System.Type instance representing the type? You mean like this? from System.Collections.Generic import List runtimeType = clr.GetClrType(List) Cool - I need it too :-) -- -- Lukas ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Docstrings on stuff in clr module
Hello IronPython team, Could we please have better docstrings on some of the stuff in the clr module. Specifically: Module docstring: module() module(dict dictionary) module(module parent, dict dictionary) module(module parent, dict dictionary, bool isVisible) def AddReferenceToTypeLibrary(arg0, arg1): AddReferenceToTypeLibrary(CodeContext context, object rcw) AddReferenceToTypeLibrary(CodeContext context, Guid typeLibGuid) pass class ArgChecker(object): ArgChecker(Array[object] prms) def CompileModules(arg0, arg1, arg2, arg3=None): CompileModules(CodeContext context, str assemblyName, dict kwArgs, Array[str] filenames) pass def Deserialize(arg0, arg1): object Deserialize(str serializationFormat, str data) return object() def GetClrType(arg0): Type GetClrType(Type type) return Type() def GetCurrentRuntime(arg0): ScriptDomainManager GetCurrentRuntime(CodeContext context) return ScriptDomainManager() def GetDynamicType(arg0): type GetDynamicType(Type t) return type() def GetPythonType(arg0): type GetPythonType(Type t) return type() def LoadTypeLibrary(arg0, arg1): ComTypeLibInfo LoadTypeLibrary(CodeContext context, object rcw) ComTypeLibInfo LoadTypeLibrary(CodeContext context, Guid typeLibGuid) return ComTypeLibInfo() class Reference(object): StrongBox[T]() StrongBox[T](T value) class ReferencesList(List[Assembly]): ReferencesList() class ReturnChecker(object): ReturnChecker(object returnType) class RuntimeArgChecker(PythonTypeSlot): RuntimeArgChecker(object function, Array[object] expectedArgs) RuntimeArgChecker(object instance, object function, Array[object] expectedArgs) class RuntimeReturnChecker(PythonTypeSlot): RuntimeReturnChecker(object function, object expectedReturn) RuntimeReturnChecker(object instance, object function, object expectedReturn) def GetAttribute(self, arg0, arg1): object GetAttribute(self, object instance, object owner) return object() def Self(arg): object Self() return object() def Serialize(arg0): tuple Serialize(object self) return tuple() def SetCommandDispatcher(arg0, arg1): CommandDispatcher SetCommandDispatcher(CodeContext context, CommandDispatcher dispatcher) return CommandDispatcher() def Use(arg0, arg1): object Use(CodeContext context, str name) object Use(CodeContext context, str path, str language) return object() def accepts(arg0=None): object accepts(Array[object] types) return object() def returns(arg0): object returns(object type) return object() (Above from the Wing PI file generated for the clr module.) :-) Thanks Michael -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Question on Multiple Discrete IronPython sessions in a single process
Hello, everyone! I am working on an service manager application that provides embedded python support through a small set of generalized classes: PythonService, PythonSession, and PythonClass. A client application asks the service manager for the PythonService object and then asks the PythonService object for a new PythonSession object. The PythonSession object is used to access embedded python through a small set of generalized methods. The PythonClass object is used to wrap a python class instance. The key requirement in this is each client must have its own python session, independent of any other sessions currently running. I've got this to work with CPython (specifically, python 2.5.4), by careful use of the global interpreter lock and swapping the thread state. IronPython 2.0.1 has a nicer way of implementing all of this by using the CreateEngine() to create a new python engine. However, in IronPython I've run into what appears to be a significant limitation that may prevent me from using IronPython in this particular situation as an embedded language. The limitation is when I import a python package from disk into IronPython (using IronPython.Hosting.Python.ImportModule()) in one session and then import the same package into a different session, it turns out that both sessions are pulling from the same module's scope. That is, if I make changes to the module's scope in one session (for example, changing a global variable), that change appears in the other session. After tracing execution in the IronPython 2.0.1 code, it turns out that a module is cached in the LanguageContext (PythonContext) object, which in turn is a singleton in DLR, as it is associated with the language type. This is okay if an application is embedding IronPython itself but in my scenario, this prevents multiple discrete python sessions in a single application. Ideally, I would expect to see the system state be stored in the python engine (ScriptEngine) or python runtime (ScriptRuntime) objects. Is there a way around this limitation? Can I somehow create a unique PythonContext object for each of my python sessions so I get a completely discrete python instance in each session with no crosstalk? Or do I have to resort to modifying the IronPython source to accomplish this (which I'm loathe to do since then I would have to maintain it going forward)? Thank you for your time and consideration in this matter. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Docstrings on stuff in clr module
Yes - I've opened a bug (22235 - http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). I want to generally improve the doc strings everywhere. I've slowly been pushing on this and my ultimate goal is to get all of the doc strings moved into XML comments and then we can read them from there. Then we just need to go through a big push and add XML doc comments everywhere :) If other people have APIs they want doc strings on please add them to the comments. But I can see clr being particularly problematic as it otherwise lacks documentation. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, April 30, 2009 8:11 AM To: Discussion of IronPython Subject: [IronPython] Docstrings on stuff in clr module Hello IronPython team, Could we please have better docstrings on some of the stuff in the clr module. Specifically: Module docstring: module() module(dict dictionary) module(module parent, dict dictionary) module(module parent, dict dictionary, bool isVisible) def AddReferenceToTypeLibrary(arg0, arg1): AddReferenceToTypeLibrary(CodeContext context, object rcw) AddReferenceToTypeLibrary(CodeContext context, Guid typeLibGuid) pass class ArgChecker(object): ArgChecker(Array[object] prms) def CompileModules(arg0, arg1, arg2, arg3=None): CompileModules(CodeContext context, str assemblyName, dict kwArgs, Array[str] filenames) pass def Deserialize(arg0, arg1): object Deserialize(str serializationFormat, str data) return object() def GetClrType(arg0): Type GetClrType(Type type) return Type() def GetCurrentRuntime(arg0): ScriptDomainManager GetCurrentRuntime(CodeContext context) return ScriptDomainManager() def GetDynamicType(arg0): type GetDynamicType(Type t) return type() def GetPythonType(arg0): type GetPythonType(Type t) return type() def LoadTypeLibrary(arg0, arg1): ComTypeLibInfo LoadTypeLibrary(CodeContext context, object rcw) ComTypeLibInfo LoadTypeLibrary(CodeContext context, Guid typeLibGuid) return ComTypeLibInfo() class Reference(object): StrongBox[T]() StrongBox[T](T value) class ReferencesList(List[Assembly]): ReferencesList() class ReturnChecker(object): ReturnChecker(object returnType) class RuntimeArgChecker(PythonTypeSlot): RuntimeArgChecker(object function, Array[object] expectedArgs) RuntimeArgChecker(object instance, object function, Array[object] expectedArgs) class RuntimeReturnChecker(PythonTypeSlot): RuntimeReturnChecker(object function, object expectedReturn) RuntimeReturnChecker(object instance, object function, object expectedReturn) def GetAttribute(self, arg0, arg1): object GetAttribute(self, object instance, object owner) return object() def Self(arg): object Self() return object() def Serialize(arg0): tuple Serialize(object self) return tuple() def SetCommandDispatcher(arg0, arg1): CommandDispatcher SetCommandDispatcher(CodeContext context, CommandDispatcher dispatcher) return CommandDispatcher() def Use(arg0, arg1): object Use(CodeContext context, str name) object Use(CodeContext context, str path, str language) return object() def accepts(arg0=None): object accepts(Array[object] types) return object() def returns(arg0): object returns(object type) return object() (Above from the Wing PI file generated for the clr module.) :-) Thanks Michael -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
You mention CreateEngine but are you also creating multiple runtimes? You're only allowed 1 ScriptEngine of a given type per ScriptRuntime. So you should create a new ScriptRuntime and then get the Python engine for each runtime and then be isolated. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lepisto, Stephen P Sent: Thursday, April 30, 2009 8:26 AM To: users@lists.ironpython.com Subject: [IronPython] Question on Multiple Discrete IronPython sessions in a single process Hello, everyone! I am working on an service manager application that provides embedded python support through a small set of generalized classes: PythonService, PythonSession, and PythonClass. A client application asks the service manager for the PythonService object and then asks the PythonService object for a new PythonSession object. The PythonSession object is used to access embedded python through a small set of generalized methods. The PythonClass object is used to wrap a python class instance. The key requirement in this is each client must have its own python session, independent of any other sessions currently running. I've got this to work with CPython (specifically, python 2.5.4), by careful use of the global interpreter lock and swapping the thread state. IronPython 2.0.1 has a nicer way of implementing all of this by using the CreateEngine() to create a new python engine. However, in IronPython I've run into what appears to be a significant limitation that may prevent me from using IronPython in this particular situation as an embedded language. The limitation is when I import a python package from disk into IronPython (using IronPython.Hosting.Python.ImportModule()) in one session and then import the same package into a different session, it turns out that both sessions are pulling from the same module's scope. That is, if I make changes to the module's scope in one session (for example, changing a global variable), that change appears in the other session. After tracing execution in the IronPython 2.0.1 code, it turns out that a module is cached in the LanguageContext (PythonContext) object, which in turn is a singleton in DLR, as it is associated with the language type. This is okay if an application is embedding IronPython itself but in my scenario, this prevents multiple discrete python sessions in a single application. Ideally, I would expect to see the system state be stored in the python engine (ScriptEngine) or python runtime (ScriptRuntime) objects. Is there a way around this limitation? Can I somehow create a unique PythonContext object for each of my python sessions so I get a completely discrete python instance in each session with no crosstalk? Or do I have to resort to modifying the IronPython source to accomplish this (which I'm loathe to do since then I would have to maintain it going forward)? Thank you for your time and consideration in this matter. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
Dino Viehland wrote: You mention CreateEngine but are you also creating multiple runtimes? You’re only allowed 1 ScriptEngine of a given type per ScriptRuntime. So you should create a new ScriptRuntime and then get the Python engine for each runtime and then be isolated. If you call Python.CreateEngine() twice it gives you two different engine objects with what *appear* to be different runtimes. If you then call Python.ImportModule for the same module but passing in the two different engines, you get two different (non-identical objects) ScriptScopes - but changes in one are reflected in the other. Is CreateEngine not the correct way to get isolated engines? Michael *From:* users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lepisto, Stephen P *Sent:* Thursday, April 30, 2009 8:26 AM *To:* users@lists.ironpython.com *Subject:* [IronPython] Question on Multiple Discrete IronPython sessions in a single process Hello, everyone! I am working on an service manager application that provides embedded python support through a small set of generalized classes: PythonService, PythonSession, and PythonClass. A client application asks the service manager for the PythonService object and then asks the PythonService object for a new PythonSession object. The PythonSession object is used to access embedded python through a small set of generalized methods. The PythonClass object is used to wrap a python class instance. The key requirement in this is each client must have its own python session, independent of any other sessions currently running. I’ve got this to work with CPython (specifically, python 2.5.4), by careful use of the global interpreter lock and swapping the thread state. IronPython 2.0.1 has a nicer way of implementing all of this by using the CreateEngine() to create a new python engine. However, in IronPython I’ve run into what appears to be a significant limitation that may prevent me from using IronPython in this particular situation as an embedded language. The limitation is when I import a python package from disk into IronPython (using IronPython.Hosting.Python.ImportModule()) in one session and then import the same package into a different session, it turns out that both sessions are pulling from the same module’s scope. That is, if I make changes to the module’s scope in one session (for example, changing a global variable), that change appears in the other session. After tracing execution in the IronPython 2.0.1 code, it turns out that a module is cached in the LanguageContext (PythonContext) object, which in turn is a singleton in DLR, as it is associated with the language type. This is okay if an application is embedding IronPython itself but in my scenario, this prevents multiple discrete python sessions in a single application. Ideally, I would expect to see the system state be stored in the python engine (ScriptEngine) or python runtime (ScriptRuntime) objects. Is there a way around this limitation? Can I somehow create a unique PythonContext object for each of my python sessions so I get a completely discrete python instance in each session with no crosstalk? Or do I have to resort to modifying the IronPython source to accomplish this (which I’m loathe to do since then I would have to maintain it going forward)? Thank you for your time and consideration in this matter. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
On Thu, Apr 30, 2009 at 9:08 AM, Michael Foord fuzzy...@voidspace.org.uk wrote: Is CreateEngine not the correct way to get isolated engines? Yes, but it looks like ImportModule is importing into some kind of shared state. -- Curt Hagenlocher c...@hagenlocher.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Docstrings on stuff in clr module
Is there a standardized protocol for XML docstrings? Then what software would you use to process them? On Thu, Apr 30, 2009 at 10:54 AM, Dino Viehland di...@microsoft.com wrote: Yes - I've opened a bug (22235 - http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). I want to generally improve the doc strings everywhere. I've slowly been pushing on this and my ultimate goal is to get all of the doc strings moved into XML comments and then we can read them from there. Then we just need to go through a big push and add XML doc comments everywhere :) If other people have APIs they want doc strings on please add them to the comments. But I can see clr being particularly problematic as it otherwise lacks documentation. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Docstrings on stuff in clr module
Dino Viehland wrote: Yes - I've opened a bug (22235 - http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). I want to generally improve the doc strings everywhere. I've slowly been pushing on this and my ultimate goal is to get all of the doc strings moved into XML comments and then we can read them from there. Then we just need to go through a big push and add XML doc comments everywhere :) If other people have APIs they want doc strings on please add them to the comments. But I can see clr being particularly problematic as it otherwise lacks documentation. Thanks Dino. Yes it was particularly the lack of documentation for the clr module that I was hoping to alleviate. Docstrings in XML. Well I never... Michael -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, April 30, 2009 8:11 AM To: Discussion of IronPython Subject: [IronPython] Docstrings on stuff in clr module Hello IronPython team, Could we please have better docstrings on some of the stuff in the clr module. Specifically: Module docstring: module() module(dict dictionary) module(module parent, dict dictionary) module(module parent, dict dictionary, bool isVisible) def AddReferenceToTypeLibrary(arg0, arg1): AddReferenceToTypeLibrary(CodeContext context, object rcw) AddReferenceToTypeLibrary(CodeContext context, Guid typeLibGuid) pass class ArgChecker(object): ArgChecker(Array[object] prms) def CompileModules(arg0, arg1, arg2, arg3=None): CompileModules(CodeContext context, str assemblyName, dict kwArgs, Array[str] filenames) pass def Deserialize(arg0, arg1): object Deserialize(str serializationFormat, str data) return object() def GetClrType(arg0): Type GetClrType(Type type) return Type() def GetCurrentRuntime(arg0): ScriptDomainManager GetCurrentRuntime(CodeContext context) return ScriptDomainManager() def GetDynamicType(arg0): type GetDynamicType(Type t) return type() def GetPythonType(arg0): type GetPythonType(Type t) return type() def LoadTypeLibrary(arg0, arg1): ComTypeLibInfo LoadTypeLibrary(CodeContext context, object rcw) ComTypeLibInfo LoadTypeLibrary(CodeContext context, Guid typeLibGuid) return ComTypeLibInfo() class Reference(object): StrongBox[T]() StrongBox[T](T value) class ReferencesList(List[Assembly]): ReferencesList() class ReturnChecker(object): ReturnChecker(object returnType) class RuntimeArgChecker(PythonTypeSlot): RuntimeArgChecker(object function, Array[object] expectedArgs) RuntimeArgChecker(object instance, object function, Array[object] expectedArgs) class RuntimeReturnChecker(PythonTypeSlot): RuntimeReturnChecker(object function, object expectedReturn) RuntimeReturnChecker(object instance, object function, object expectedReturn) def GetAttribute(self, arg0, arg1): object GetAttribute(self, object instance, object owner) return object() def Self(arg): object Self() return object() def Serialize(arg0): tuple Serialize(object self) return tuple() def SetCommandDispatcher(arg0, arg1): CommandDispatcher SetCommandDispatcher(CodeContext context, CommandDispatcher dispatcher) return CommandDispatcher() def Use(arg0, arg1): object Use(CodeContext context, str name) object Use(CodeContext context, str path, str language) return object() def accepts(arg0=None): object accepts(Array[object] types) return object() def returns(arg0): object returns(object type) return object() (Above from the Wing PI file generated for the clr module.) :-) Thanks Michael -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
Oh, Python.CreateEngine will give you independent engines as it'll create a new runtime each time. I was thinking this was one of the normal DLR hosting APIs but I guess there is no create engine there, just GetEngine. Stephen, do you have a small simple repro for this? If you're using Python.CreateEngine it should just work. The PythonContext is one to one w/ the ScriptEngine so it's the right spot for the state to live. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, April 30, 2009 9:08 AM To: Discussion of IronPython Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process Dino Viehland wrote: You mention CreateEngine but are you also creating multiple runtimes? You're only allowed 1 ScriptEngine of a given type per ScriptRuntime. So you should create a new ScriptRuntime and then get the Python engine for each runtime and then be isolated. If you call Python.CreateEngine() twice it gives you two different engine objects with what *appear* to be different runtimes. If you then call Python.ImportModule for the same module but passing in the two different engines, you get two different (non-identical objects) ScriptScopes - but changes in one are reflected in the other. Is CreateEngine not the correct way to get isolated engines? Michael *From:* users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lepisto, Stephen P *Sent:* Thursday, April 30, 2009 8:26 AM *To:* users@lists.ironpython.com *Subject:* [IronPython] Question on Multiple Discrete IronPython sessions in a single process Hello, everyone! I am working on an service manager application that provides embedded python support through a small set of generalized classes: PythonService, PythonSession, and PythonClass. A client application asks the service manager for the PythonService object and then asks the PythonService object for a new PythonSession object. The PythonSession object is used to access embedded python through a small set of generalized methods. The PythonClass object is used to wrap a python class instance. The key requirement in this is each client must have its own python session, independent of any other sessions currently running. I've got this to work with CPython (specifically, python 2.5.4), by careful use of the global interpreter lock and swapping the thread state. IronPython 2.0.1 has a nicer way of implementing all of this by using the CreateEngine() to create a new python engine. However, in IronPython I've run into what appears to be a significant limitation that may prevent me from using IronPython in this particular situation as an embedded language. The limitation is when I import a python package from disk into IronPython (using IronPython.Hosting.Python.ImportModule()) in one session and then import the same package into a different session, it turns out that both sessions are pulling from the same module's scope. That is, if I make changes to the module's scope in one session (for example, changing a global variable), that change appears in the other session. After tracing execution in the IronPython 2.0.1 code, it turns out that a module is cached in the LanguageContext (PythonContext) object, which in turn is a singleton in DLR, as it is associated with the language type. This is okay if an application is embedding IronPython itself but in my scenario, this prevents multiple discrete python sessions in a single application. Ideally, I would expect to see the system state be stored in the python engine (ScriptEngine) or python runtime (ScriptRuntime) objects. Is there a way around this limitation? Can I somehow create a unique PythonContext object for each of my python sessions so I get a completely discrete python instance in each session with no crosstalk? Or do I have to resort to modifying the IronPython source to accomplish this (which I'm loathe to do since then I would have to maintain it going forward)? Thank you for your time and consideration in this matter. - --- ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
And this works for me:
using System;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
class foo {
static void Main(string[] args)
{
var engine = Python.CreateEngine();
ScriptScope scope1 = engine.ImportModule(foo);
var engine2 = Python.CreateEngine();
ScriptScope scope2 = engine2.ImportModule(foo);
scope1.SetVariable(foo, 42);
object res;
if(scope2.TryGetVariable(foo, out res)) {
Console.WriteLine(res);
} else {
Console.WriteLine(no foo);
}
}
}
Foo.py:
print 'hello'
Printing out:
hello
hello
no foo
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
You mention CreateEngine but are you also creating multiple runtimes?
You're only allowed 1 ScriptEngine of a given type per ScriptRuntime.
So you should create a new ScriptRuntime and then get the Python
engine for each runtime and then be isolated.
If you call Python.CreateEngine() twice it gives you two different
engine objects with what *appear* to be different runtimes.
If you then call Python.ImportModule for the same module but passing in
the two different engines, you get two different (non-identical
objects)
ScriptScopes - but changes in one are reflected in the other.
Is CreateEngine not the correct way to get isolated engines?
Michael
*From:* users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lepisto,
Stephen P
*Sent:* Thursday, April 30, 2009 8:26 AM
*To:* users@lists.ironpython.com
*Subject:* [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Hello, everyone!
I am working on an service manager application that provides embedded
python support through a small set of generalized classes:
PythonService, PythonSession, and PythonClass. A client application
asks the service manager for the PythonService object and then asks
the PythonService object for a new PythonSession object. The
PythonSession object is used to access embedded python through a
small
set of generalized methods. The PythonClass object is used to wrap a
python class instance.
The key requirement in this is each client must have its own python
session, independent of any other sessions currently running. I've
got
this to work with CPython (specifically, python 2.5.4), by careful
use
of the global interpreter lock and swapping the thread state.
IronPython 2.0.1 has a nicer way of implementing all of this by using
the CreateEngine() to create a new python engine. However, in
IronPython I've run into what appears to be a significant limitation
that may prevent me from using IronPython in this particular
situation
as an embedded language.
The limitation is when I import a python package from disk into
IronPython (using IronPython.Hosting.Python.ImportModule()) in one
session and then import the same package into a different session, it
turns out that both sessions are pulling from the same module's
scope.
That is, if I make changes to the module's scope in one session (for
example, changing a global variable), that change appears in the
other
session.
After tracing execution in the IronPython 2.0.1 code, it turns out
that a module is cached in the LanguageContext (PythonContext)
object,
which in turn is a singleton in DLR, as it is associated with the
language type. This is okay if an application is embedding IronPython
itself but in my scenario, this prevents multiple discrete python
sessions in a single application. Ideally, I would expect to see the
system state be stored in the python engine (ScriptEngine) or python
runtime (ScriptRuntime) objects.
Is there a way around this limitation? Can I somehow create a unique
PythonContext object for each of my python sessions so I get a
completely discrete python instance in each session with no
crosstalk?
Or do I have to resort to modifying the IronPython source to
accomplish this (which I'm loathe to do since then I would have to
maintain it going forward)?
Thank you for your time and consideration in this matter.
-
---
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
___
Users mailing list
Users@lists.ironpython.com
Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
Dino Viehland wrote:
And this works for me:
I just did the equivalent, from *inside* IronPython which may make a
difference, with the 'os' module and got the opposite result:
import clr
clr.AddReference('IronPython')
from IronPython.Hosting import Python#
e1 = Python.CreateEngine()
e2 = Python.CreateEngine()
os1 = Python.ImportModule(e1, 'os')
os2 = Python.ImportModule(e2, 'os')
os1
Microsoft.Scripting.Hosting.ScriptScope object at 0x002B
[Microsoft
.Scripting.Hosting.ScriptScope]
os1 is os2
False
os1.SetVariable('foo', 'bar')
os2.GetVariable('foo')
'bar'
All the best,
Michael
using System;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
class foo {
static void Main(string[] args)
{
var engine = Python.CreateEngine();
ScriptScope scope1 = engine.ImportModule(foo);
var engine2 = Python.CreateEngine();
ScriptScope scope2 = engine2.ImportModule(foo);
scope1.SetVariable(foo, 42);
object res;
if(scope2.TryGetVariable(foo, out res)) {
Console.WriteLine(res);
} else {
Console.WriteLine(no foo);
}
}
}
Foo.py:
print 'hello'
Printing out:
hello
hello
no foo
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
You mention CreateEngine but are you also creating multiple runtimes?
You're only allowed 1 ScriptEngine of a given type per ScriptRuntime.
So you should create a new ScriptRuntime and then get the Python
engine for each runtime and then be isolated.
If you call Python.CreateEngine() twice it gives you two different
engine objects with what *appear* to be different runtimes.
If you then call Python.ImportModule for the same module but passing in
the two different engines, you get two different (non-identical
objects)
ScriptScopes - but changes in one are reflected in the other.
Is CreateEngine not the correct way to get isolated engines?
Michael
*From:* users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lepisto,
Stephen P
*Sent:* Thursday, April 30, 2009 8:26 AM
*To:* users@lists.ironpython.com
*Subject:* [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Hello, everyone!
I am working on an service manager application that provides embedded
python support through a small set of generalized classes:
PythonService, PythonSession, and PythonClass. A client application
asks the service manager for the PythonService object and then asks
the PythonService object for a new PythonSession object. The
PythonSession object is used to access embedded python through a
small
set of generalized methods. The PythonClass object is used to wrap a
python class instance.
The key requirement in this is each client must have its own python
session, independent of any other sessions currently running. I've
got
this to work with CPython (specifically, python 2.5.4), by careful
use
of the global interpreter lock and swapping the thread state.
IronPython 2.0.1 has a nicer way of implementing all of this by using
the CreateEngine() to create a new python engine. However, in
IronPython I've run into what appears to be a significant limitation
that may prevent me from using IronPython in this particular
situation
as an embedded language.
The limitation is when I import a python package from disk into
IronPython (using IronPython.Hosting.Python.ImportModule()) in one
session and then import the same package into a different session, it
turns out that both sessions are pulling from the same module's
scope.
That is, if I make changes to the module's scope in one session (for
example, changing a global variable), that change appears in the
other
session.
After tracing execution in the IronPython 2.0.1 code, it turns out
that a module is cached in the LanguageContext (PythonContext)
object,
which in turn is a singleton in DLR, as it is associated with the
language type. This is okay if an application is embedding IronPython
itself but in my scenario, this prevents multiple discrete python
sessions in a single application. Ideally, I would expect to see the
system state be stored in the python engine (ScriptEngine) or python
runtime (ScriptRuntime) objects.
Is there a way around this limitation? Can I somehow create a unique
PythonContext object for each of my python sessions so I get a
completely discrete python instance in each session with no
crosstalk?
Or do I have to resort to modifying the IronPython
Re: [IronPython] Is Silverlight 3 beta supported in Ironpython yet?
Yes, the binaries that ship in IronPython will work in SL3 Beta just fine. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Kristian Jaksch Sent: Thursday, April 30, 2009 8:01 AM To: users@lists.ironpython.com Subject: [IronPython] Is Silverlight 3 beta supported in Ironpython yet? Does Ironpython support Silverlight 3 beta yet? /Kristian ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Docstrings on stuff in clr module
There's the format the compiler generates w/ the /doc: option - I'm not sure how standardized it is but it's at least consistent :) When you install the .NET framework SDK you get XML doc files for all of the .NET framework installed into %WINDIR%\Microsoft.NET\Framework\v2.0.50727\en\... (or some other language instead of en). We already support reading and producing __doc__ from these XML files (using .NET's xml reading support and just looking for the values we know we need to pull out) it's just that we do something different for IronPython's own doc strings. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Jonathan March Sent: Thursday, April 30, 2009 9:20 AM To: Discussion of IronPython Subject: Re: [IronPython] Docstrings on stuff in clr module Is there a standardized protocol for XML docstrings? Then what software would you use to process them? On Thu, Apr 30, 2009 at 10:54 AM, Dino Viehland di...@microsoft.commailto:di...@microsoft.com wrote: Yes - I've opened a bug (22235 - http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). I want to generally improve the doc strings everywhere. I've slowly been pushing on this and my ultimate goal is to get all of the doc strings moved into XML comments and then we can read them from there. Then we just need to go through a big push and add XML doc comments everywhere :) If other people have APIs they want doc strings on please add them to the comments. But I can see clr being particularly problematic as it otherwise lacks documentation. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Docstrings on stuff in clr module
Dino Viehland wrote: There’s the format the compiler generates w/ the /doc: option – I’m not sure how standardized it is but it’s at least consistent J When you install the .NET framework SDK you get XML doc files for all of the .NET framework installed into %WINDIR%\Microsoft.NET\Framework\v2.0.50727\en\... (or some other language instead of en). We already support reading and producing __doc__ from these XML files (using .NET’s xml reading support and just looking for the values we know we need to pull out) it’s just that we do something different for IronPython’s own doc strings. Yes - and those docstrings on the .NET types are *very* useful. :-) (So thanks for the integration.) I now get them in the Wing IDE source assistant when I am working with .NET objects. Michael *From:* users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Jonathan March *Sent:* Thursday, April 30, 2009 9:20 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Docstrings on stuff in clr module Is there a standardized protocol for XML docstrings? Then what software would you use to process them? On Thu, Apr 30, 2009 at 10:54 AM, Dino Viehland di...@microsoft.com mailto:di...@microsoft.com wrote: Yes - I've opened a bug (22235 - http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). I want to generally improve the doc strings everywhere. I've slowly been pushing on this and my ultimate goal is to get all of the doc strings moved into XML comments and then we can read them from there. Then we just need to go through a big push and add XML doc comments everywhere :) If other people have APIs they want doc strings on please add them to the comments. But I can see clr being particularly problematic as it otherwise lacks documentation. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
Dino,
That example you provided produced the following output under IronPython 2.0.1:
hello
42
In other words, the two sessions appear to be sharing the same module in
IronPython 2.0.1.
Are you using a later version of IronPython where this might be fixed?
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Thursday, April 30, 2009 9:28 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions in
a single process
And this works for me:
using System;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
class foo {
static void Main(string[] args)
{
var engine = Python.CreateEngine();
ScriptScope scope1 = engine.ImportModule(foo);
var engine2 = Python.CreateEngine();
ScriptScope scope2 = engine2.ImportModule(foo);
scope1.SetVariable(foo, 42);
object res;
if(scope2.TryGetVariable(foo, out res)) {
Console.WriteLine(res);
} else {
Console.WriteLine(no foo);
}
}
}
Foo.py:
print 'hello'
Printing out:
hello
hello
no foo
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
You mention CreateEngine but are you also creating multiple runtimes?
You're only allowed 1 ScriptEngine of a given type per ScriptRuntime.
So you should create a new ScriptRuntime and then get the Python
engine for each runtime and then be isolated.
If you call Python.CreateEngine() twice it gives you two different
engine objects with what *appear* to be different runtimes.
If you then call Python.ImportModule for the same module but passing in
the two different engines, you get two different (non-identical
objects)
ScriptScopes - but changes in one are reflected in the other.
Is CreateEngine not the correct way to get isolated engines?
Michael
*From:* users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lepisto,
Stephen P
*Sent:* Thursday, April 30, 2009 8:26 AM
*To:* users@lists.ironpython.com
*Subject:* [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Hello, everyone!
I am working on an service manager application that provides embedded
python support through a small set of generalized classes:
PythonService, PythonSession, and PythonClass. A client application
asks the service manager for the PythonService object and then asks
the PythonService object for a new PythonSession object. The
PythonSession object is used to access embedded python through a
small
set of generalized methods. The PythonClass object is used to wrap a
python class instance.
The key requirement in this is each client must have its own python
session, independent of any other sessions currently running. I've
got
this to work with CPython (specifically, python 2.5.4), by careful
use
of the global interpreter lock and swapping the thread state.
IronPython 2.0.1 has a nicer way of implementing all of this by using
the CreateEngine() to create a new python engine. However, in
IronPython I've run into what appears to be a significant limitation
that may prevent me from using IronPython in this particular
situation
as an embedded language.
The limitation is when I import a python package from disk into
IronPython (using IronPython.Hosting.Python.ImportModule()) in one
session and then import the same package into a different session, it
turns out that both sessions are pulling from the same module's
scope.
That is, if I make changes to the module's scope in one session (for
example, changing a global variable), that change appears in the
other
session.
After tracing execution in the IronPython 2.0.1 code, it turns out
that a module is cached in the LanguageContext (PythonContext)
object,
which in turn is a singleton in DLR, as it is associated with the
language type. This is okay if an application is embedding IronPython
itself but in my scenario, this prevents multiple discrete python
sessions in a single application. Ideally, I would expect to see the
system state be stored in the python engine (ScriptEngine) or python
runtime (ScriptRuntime) objects.
Is there a way around this limitation? Can I somehow create a unique
PythonContext object for each of my python sessions so I get a
completely discrete python instance in each session with no
crosstalk?
Or do I have to resort to modifying the IronPython source to
accomplish this (which
Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
Ok, it's broken on 2.0.1 but not on 2.6. I've opened a 2.0.2 bug:
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 9:47 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
And this works for me:
I just did the equivalent, from *inside* IronPython which may make a
difference, with the 'os' module and got the opposite result:
import clr
clr.AddReference('IronPython')
from IronPython.Hosting import Python#
e1 = Python.CreateEngine()
e2 = Python.CreateEngine()
os1 = Python.ImportModule(e1, 'os')
os2 = Python.ImportModule(e2, 'os')
os1
Microsoft.Scripting.Hosting.ScriptScope object at 0x002B
[Microsoft
.Scripting.Hosting.ScriptScope]
os1 is os2
False
os1.SetVariable('foo', 'bar')
os2.GetVariable('foo')
'bar'
All the best,
Michael
using System;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
class foo {
static void Main(string[] args)
{
var engine = Python.CreateEngine();
ScriptScope scope1 = engine.ImportModule(foo);
var engine2 = Python.CreateEngine();
ScriptScope scope2 = engine2.ImportModule(foo);
scope1.SetVariable(foo, 42);
object res;
if(scope2.TryGetVariable(foo, out res)) {
Console.WriteLine(res);
} else {
Console.WriteLine(no foo);
}
}
}
Foo.py:
print 'hello'
Printing out:
hello
hello
no foo
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
You mention CreateEngine but are you also creating multiple
runtimes?
You're only allowed 1 ScriptEngine of a given type per
ScriptRuntime.
So you should create a new ScriptRuntime and then get the Python
engine for each runtime and then be isolated.
If you call Python.CreateEngine() twice it gives you two different
engine objects with what *appear* to be different runtimes.
If you then call Python.ImportModule for the same module but passing
in
the two different engines, you get two different (non-identical
objects)
ScriptScopes - but changes in one are reflected in the other.
Is CreateEngine not the correct way to get isolated engines?
Michael
*From:* users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lepisto,
Stephen P
*Sent:* Thursday, April 30, 2009 8:26 AM
*To:* users@lists.ironpython.com
*Subject:* [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Hello, everyone!
I am working on an service manager application that provides
embedded
python support through a small set of generalized classes:
PythonService, PythonSession, and PythonClass. A client application
asks the service manager for the PythonService object and then asks
the PythonService object for a new PythonSession object. The
PythonSession object is used to access embedded python through a
small
set of generalized methods. The PythonClass object is used to wrap
a
python class instance.
The key requirement in this is each client must have its own python
session, independent of any other sessions currently running. I've
got
this to work with CPython (specifically, python 2.5.4), by careful
use
of the global interpreter lock and swapping the thread state.
IronPython 2.0.1 has a nicer way of implementing all of this by
using
the CreateEngine() to create a new python engine. However, in
IronPython I've run into what appears to be a significant
limitation
that may prevent me from using IronPython in this particular
situation
as an embedded language.
The limitation is when I import a python package from disk into
IronPython (using IronPython.Hosting.Python.ImportModule()) in one
session and then import the same package into a different session,
it
turns out that both sessions are pulling from the same module's
scope.
That is, if I make changes to the module's scope in one session
(for
example, changing a global variable), that change appears in the
other
session.
After tracing execution in the IronPython 2.0.1 code, it turns out
that a module is cached in the LanguageContext (PythonContext)
object,
which in turn is a singleton in DLR, as it is associated with the
[IronPython] 2.6 Release Plan
Based upon the feedback from the mailing list here's the 2.6 release plan and list of new features: http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Plan Let me know if you have any questions or think there's areas we should include more info on. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
Looks like our threads crossed. Yep, I was using the current 2.6 branch.
I opened a bug to fix this in 2.0.2
(http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239).
Thanks for reporting this - this is a very bad bug.
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Lepisto, Stephen P
Sent: Thursday, April 30, 2009 10:10 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino,
That example you provided produced the following output under
IronPython 2.0.1:
hello
42
In other words, the two sessions appear to be sharing the same module
in IronPython 2.0.1.
Are you using a later version of IronPython where this might be fixed?
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Thursday, April 30, 2009 9:28 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
And this works for me:
using System;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
class foo {
static void Main(string[] args)
{
var engine = Python.CreateEngine();
ScriptScope scope1 = engine.ImportModule(foo);
var engine2 = Python.CreateEngine();
ScriptScope scope2 = engine2.ImportModule(foo);
scope1.SetVariable(foo, 42);
object res;
if(scope2.TryGetVariable(foo, out res)) {
Console.WriteLine(res);
} else {
Console.WriteLine(no foo);
}
}
}
Foo.py:
print 'hello'
Printing out:
hello
hello
no foo
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
You mention CreateEngine but are you also creating multiple
runtimes?
You're only allowed 1 ScriptEngine of a given type per
ScriptRuntime.
So you should create a new ScriptRuntime and then get the Python
engine for each runtime and then be isolated.
If you call Python.CreateEngine() twice it gives you two different
engine objects with what *appear* to be different runtimes.
If you then call Python.ImportModule for the same module but passing
in
the two different engines, you get two different (non-identical
objects)
ScriptScopes - but changes in one are reflected in the other.
Is CreateEngine not the correct way to get isolated engines?
Michael
*From:* users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lepisto,
Stephen P
*Sent:* Thursday, April 30, 2009 8:26 AM
*To:* users@lists.ironpython.com
*Subject:* [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Hello, everyone!
I am working on an service manager application that provides
embedded
python support through a small set of generalized classes:
PythonService, PythonSession, and PythonClass. A client application
asks the service manager for the PythonService object and then asks
the PythonService object for a new PythonSession object. The
PythonSession object is used to access embedded python through a
small
set of generalized methods. The PythonClass object is used to wrap
a
python class instance.
The key requirement in this is each client must have its own python
session, independent of any other sessions currently running. I've
got
this to work with CPython (specifically, python 2.5.4), by careful
use
of the global interpreter lock and swapping the thread state.
IronPython 2.0.1 has a nicer way of implementing all of this by
using
the CreateEngine() to create a new python engine. However, in
IronPython I've run into what appears to be a significant
limitation
that may prevent me from using IronPython in this particular
situation
as an embedded language.
The limitation is when I import a python package from disk into
IronPython (using IronPython.Hosting.Python.ImportModule()) in one
session and then import the same package into a different session,
it
turns out that both sessions are pulling from the same module's
scope.
That is, if I make changes to the module's scope in one session
(for
example, changing a global variable), that change appears in the
other
session.
After tracing execution in the IronPython 2.0.1 code, it turns out
that a module is cached in the LanguageContext (PythonContext)
object,
which in turn is a
Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
I voted for fixing the bug. In the meantime, I will be putting on hold the use
of IronPython as an embedded language in my project until this is fixed or
IronPython 2.6 is released (if I can convince my manager and team it's a good
idea to move to python 2.6 but it will affect a lot of people).
Thank you for the prompt responses!
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Thursday, April 30, 2009 10:23 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions in
a single process
Looks like our threads crossed. Yep, I was using the current 2.6 branch.
I opened a bug to fix this in 2.0.2
(http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239).
Thanks for reporting this - this is a very bad bug.
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Lepisto, Stephen P
Sent: Thursday, April 30, 2009 10:10 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino,
That example you provided produced the following output under
IronPython 2.0.1:
hello
42
In other words, the two sessions appear to be sharing the same module
in IronPython 2.0.1.
Are you using a later version of IronPython where this might be fixed?
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Thursday, April 30, 2009 9:28 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
And this works for me:
using System;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
class foo {
static void Main(string[] args)
{
var engine = Python.CreateEngine();
ScriptScope scope1 = engine.ImportModule(foo);
var engine2 = Python.CreateEngine();
ScriptScope scope2 = engine2.ImportModule(foo);
scope1.SetVariable(foo, 42);
object res;
if(scope2.TryGetVariable(foo, out res)) {
Console.WriteLine(res);
} else {
Console.WriteLine(no foo);
}
}
}
Foo.py:
print 'hello'
Printing out:
hello
hello
no foo
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
You mention CreateEngine but are you also creating multiple
runtimes?
You're only allowed 1 ScriptEngine of a given type per
ScriptRuntime.
So you should create a new ScriptRuntime and then get the Python
engine for each runtime and then be isolated.
If you call Python.CreateEngine() twice it gives you two different
engine objects with what *appear* to be different runtimes.
If you then call Python.ImportModule for the same module but passing
in
the two different engines, you get two different (non-identical
objects)
ScriptScopes - but changes in one are reflected in the other.
Is CreateEngine not the correct way to get isolated engines?
Michael
*From:* users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lepisto,
Stephen P
*Sent:* Thursday, April 30, 2009 8:26 AM
*To:* users@lists.ironpython.com
*Subject:* [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Hello, everyone!
I am working on an service manager application that provides
embedded
python support through a small set of generalized classes:
PythonService, PythonSession, and PythonClass. A client application
asks the service manager for the PythonService object and then asks
the PythonService object for a new PythonSession object. The
PythonSession object is used to access embedded python through a
small
set of generalized methods. The PythonClass object is used to wrap
a
python class instance.
The key requirement in this is each client must have its own python
session, independent of any other sessions currently running. I've
got
this to work with CPython (specifically, python 2.5.4), by careful
use
of the global interpreter lock and swapping the thread state.
IronPython 2.0.1 has a nicer way of implementing all of this by
using
the CreateEngine() to create a new python engine. However, in
IronPython I've run into what appears to be a significant
limitation
that may prevent me from using IronPython in this particular
situation
as
Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
If you import by executing the text import modname against the
ScriptEngine instead of using the import API, you will avoid this particular
incarnation of the bug.
On Thu, Apr 30, 2009 at 10:25 AM, Lepisto, Stephen P
stephen.p.lepi...@intel.com wrote:
I voted for fixing the bug. In the meantime, I will be putting on hold the
use of IronPython as an embedded language in my project until this is fixed
or IronPython 2.6 is released (if I can convince my manager and team it's a
good idea to move to python 2.6 but it will affect a lot of people).
Thank you for the prompt responses!
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:
users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Thursday, April 30, 2009 10:23 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions
in a single process
Looks like our threads crossed. Yep, I was using the current 2.6 branch.
I opened a bug to fix this in 2.0.2 (
http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239).
Thanks for reporting this - this is a very bad bug.
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Lepisto, Stephen P
Sent: Thursday, April 30, 2009 10:10 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino,
That example you provided produced the following output under
IronPython 2.0.1:
hello
42
In other words, the two sessions appear to be sharing the same module
in IronPython 2.0.1.
Are you using a later version of IronPython where this might be fixed?
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Thursday, April 30, 2009 9:28 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
And this works for me:
using System;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
class foo {
static void Main(string[] args)
{
var engine = Python.CreateEngine();
ScriptScope scope1 = engine.ImportModule(foo);
var engine2 = Python.CreateEngine();
ScriptScope scope2 = engine2.ImportModule(foo);
scope1.SetVariable(foo, 42);
object res;
if(scope2.TryGetVariable(foo, out res)) {
Console.WriteLine(res);
} else {
Console.WriteLine(no foo);
}
}
}
Foo.py:
print 'hello'
Printing out:
hello
hello
no foo
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
You mention CreateEngine but are you also creating multiple
runtimes?
You're only allowed 1 ScriptEngine of a given type per
ScriptRuntime.
So you should create a new ScriptRuntime and then get the Python
engine for each runtime and then be isolated.
If you call Python.CreateEngine() twice it gives you two different
engine objects with what *appear* to be different runtimes.
If you then call Python.ImportModule for the same module but passing
in
the two different engines, you get two different (non-identical
objects)
ScriptScopes - but changes in one are reflected in the other.
Is CreateEngine not the correct way to get isolated engines?
Michael
*From:* users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] *On Behalf Of *Lepisto,
Stephen P
*Sent:* Thursday, April 30, 2009 8:26 AM
*To:* users@lists.ironpython.com
*Subject:* [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Hello, everyone!
I am working on an service manager application that provides
embedded
python support through a small set of generalized classes:
PythonService, PythonSession, and PythonClass. A client application
asks the service manager for the PythonService object and then asks
the PythonService object for a new PythonSession object. The
PythonSession object is used to access embedded python through a
small
set of generalized methods. The PythonClass object is used to wrap
a
python class instance.
The key requirement in this is each client must have its own python
session, independent of any other sessions currently running. I've
got
this to work with CPython (specifically, python 2.5.4), by
Re: [IronPython] Question on Multiple Discrete IronPython sessions in a single process
Curt, thanks for the tip. In my tests, I needed to use from modname import
* since I needed the attributes in the module to be in the current scope.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Thursday, April 30, 2009 10:31 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions in
a single process
If you import by executing the text import modname against the ScriptEngine
instead of using the import API, you will avoid this particular incarnation of
the bug.
On Thu, Apr 30, 2009 at 10:25 AM, Lepisto, Stephen P
stephen.p.lepi...@intel.commailto:stephen.p.lepi...@intel.com wrote:
I voted for fixing the bug. In the meantime, I will be putting on hold the use
of IronPython as an embedded language in my project until this is fixed or
IronPython 2.6 is released (if I can convince my manager and team it's a good
idea to move to python 2.6 but it will affect a lot of people).
Thank you for the prompt responses!
-Original Message-
From:
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com]
On Behalf Of Dino Viehland
Sent: Thursday, April 30, 2009 10:23 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython sessions in
a single process
Looks like our threads crossed. Yep, I was using the current 2.6 branch.
I opened a bug to fix this in 2.0.2
(http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22239).
Thanks for reporting this - this is a very bad bug.
-Original Message-
From:
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-mailto:users-
boun...@lists.ironpython.commailto:boun...@lists.ironpython.com] On Behalf
Of Lepisto, Stephen P
Sent: Thursday, April 30, 2009 10:10 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino,
That example you provided produced the following output under
IronPython 2.0.1:
hello
42
In other words, the two sessions appear to be sharing the same module
in IronPython 2.0.1.
Are you using a later version of IronPython where this might be fixed?
-Original Message-
From:
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-mailto:users-
boun...@lists.ironpython.commailto:boun...@lists.ironpython.com] On Behalf
Of Dino Viehland
Sent: Thursday, April 30, 2009 9:28 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
And this works for me:
using System;
using IronPython.Hosting;
using Microsoft.Scripting.Hosting;
class foo {
static void Main(string[] args)
{
var engine = Python.CreateEngine();
ScriptScope scope1 = engine.ImportModule(foo);
var engine2 = Python.CreateEngine();
ScriptScope scope2 = engine2.ImportModule(foo);
scope1.SetVariable(foo, 42);
object res;
if(scope2.TryGetVariable(foo, out res)) {
Console.WriteLine(res);
} else {
Console.WriteLine(no foo);
}
}
}
Foo.py:
print 'hello'
Printing out:
hello
hello
no foo
-Original Message-
From:
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-mailto:users-
boun...@lists.ironpython.commailto:boun...@lists.ironpython.com] On
Behalf Of Michael Foord
Sent: Thursday, April 30, 2009 9:08 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Question on Multiple Discrete IronPython
sessions in a single process
Dino Viehland wrote:
You mention CreateEngine but are you also creating multiple
runtimes?
You're only allowed 1 ScriptEngine of a given type per
ScriptRuntime.
So you should create a new ScriptRuntime and then get the Python
engine for each runtime and then be isolated.
If you call Python.CreateEngine() twice it gives you two different
engine objects with what *appear* to be different runtimes.
If you then call Python.ImportModule for the same module but passing
in
the two different engines, you get two different (non-identical
objects)
ScriptScopes - but changes in one are reflected in the other.
Is CreateEngine not the correct way to get isolated engines?
Michael
*From:*
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com]
*On Behalf Of *Lepisto,
Stephen P
*Sent:* Thursday, April 30, 2009 8:26 AM
*To:* users@lists.ironpython.commailto:users@lists.ironpython.com
*Subject:*
Re: [IronPython] Docstrings on stuff in clr module
Thanks! --- .NET newb On Thu, Apr 30, 2009 at 11:37 AM, Dino Viehland di...@microsoft.com wrote: There’s the format the compiler generates w/ the /doc: option – I’m not sure how standardized it is but it’s at least consistent J When you install the .NET framework SDK you get XML doc files for all of the .NET framework installed into %WINDIR%\Microsoft.NET\Framework\v2.0.50727\en\... (or some other language instead of en). We already support reading and producing __doc__ from these XML files (using .NET’s xml reading support and just looking for the values we know we need to pull out) it’s just that we do something different for IronPython’s own doc strings. *From:* users-boun...@lists.ironpython.com [mailto: users-boun...@lists.ironpython.com] *On Behalf Of *Jonathan March *Sent:* Thursday, April 30, 2009 9:20 AM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Docstrings on stuff in clr module Is there a standardized protocol for XML docstrings? Then what software would you use to process them? On Thu, Apr 30, 2009 at 10:54 AM, Dino Viehland di...@microsoft.com wrote: Yes - I've opened a bug (22235 - http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=22235). I want to generally improve the doc strings everywhere. I've slowly been pushing on this and my ultimate goal is to get all of the doc strings moved into XML comments and then we can read them from there. Then we just need to go through a big push and add XML doc comments everywhere :) If other people have APIs they want doc strings on please add them to the comments. But I can see clr being particularly problematic as it otherwise lacks documentation. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 2.6 Release Plan
Dino Viehland wrote: Based upon the feedback from the mailing list here’s the 2.6 release plan and list of new features: http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Plan Let me know if you have any questions or think there’s areas we should include more info on. The profiler API that Curt blogged about isn't on this list. Is it an oversight or has it been dropped? I notice that there is no mention of sys._getframe; does this mean it definitely won't be something we see in 2.6? Shame there is still no sign of the csv module. ;-) Anyway - thanks for the schedule, very helpful. All the best, Michael Foord ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 2.6 Release Plan
Both of those are just oversights - thanks for the reminder. I do have an implementation of _getframe I've just held off on checking it in while I try and figure out if I can make it faster someway. Harry had been playing with around implementing a csv module. If he manages to get it all done then we'll include it. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, April 30, 2009 12:26 PM To: Discussion of IronPython Subject: Re: [IronPython] 2.6 Release Plan Dino Viehland wrote: Based upon the feedback from the mailing list here's the 2.6 release plan and list of new features: http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Pla n Let me know if you have any questions or think there's areas we should include more info on. The profiler API that Curt blogged about isn't on this list. Is it an oversight or has it been dropped? I notice that there is no mention of sys._getframe; does this mean it definitely won't be something we see in 2.6? Shame there is still no sign of the csv module. ;-) Anyway - thanks for the schedule, very helpful. All the best, Michael Foord - --- ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 2.6 Release Plan
Dino Viehland wrote: Both of those are just oversights - thanks for the reminder. I do have an implementation of _getframe I've just held off on checking it in while I try and figure out if I can make it faster someway. Harry had been playing with around implementing a csv module. If he manages to get it all done then we'll include it. All great news - thanks! Michael -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, April 30, 2009 12:26 PM To: Discussion of IronPython Subject: Re: [IronPython] 2.6 Release Plan Dino Viehland wrote: Based upon the feedback from the mailing list here's the 2.6 release plan and list of new features: http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Pla n Let me know if you have any questions or think there's areas we should include more info on. The profiler API that Curt blogged about isn't on this list. Is it an oversight or has it been dropped? I notice that there is no mention of sys._getframe; does this mean it definitely won't be something we see in 2.6? Shame there is still no sign of the csv module. ;-) Anyway - thanks for the schedule, very helpful. All the best, Michael Foord - --- ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 2.6 Release Plan
Michael Foord wrote: Dino Viehland wrote: Both of those are just oversights - thanks for the reminder. I do have an implementation of _getframe I've just held off on checking it in while I try and figure out if I can make it faster someway. Harry had been playing with around implementing a csv module. If he manages to get it all done then we'll include it. All great news - thanks! Oh, and when is 2.0.2 coming? You had to know this question was coming right? :-) Michael Michael -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, April 30, 2009 12:26 PM To: Discussion of IronPython Subject: Re: [IronPython] 2.6 Release Plan Dino Viehland wrote: Based upon the feedback from the mailing list here's the 2.6 release plan and list of new features: http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Pla n Let me know if you have any questions or think there's areas we should include more info on. The profiler API that Curt blogged about isn't on this list. Is it an oversight or has it been dropped? I notice that there is no mention of sys._getframe; does this mean it definitely won't be something we see in 2.6? Shame there is still no sign of the csv module. ;-) Anyway - thanks for the schedule, very helpful. All the best, Michael Foord - --- ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 2.6 Release Plan
Sigh, I've been putting it off trying to get all the goodies into 2.6. Now would be a good time to ask what people would like to see fixed. And if I had to take a guess I'd say it'd be a little bit after 2.6B1 but I should discuss it with the team :) -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, April 30, 2009 12:58 PM To: Discussion of IronPython Subject: Re: [IronPython] 2.6 Release Plan Michael Foord wrote: Dino Viehland wrote: Both of those are just oversights - thanks for the reminder. I do have an implementation of _getframe I've just held off on checking it in while I try and figure out if I can make it faster someway. Harry had been playing with around implementing a csv module. If he manages to get it all done then we'll include it. All great news - thanks! Oh, and when is 2.0.2 coming? You had to know this question was coming right? :-) Michael Michael -Original Message- From: users-boun...@lists.ironpython.com [mailto:users- boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, April 30, 2009 12:26 PM To: Discussion of IronPython Subject: Re: [IronPython] 2.6 Release Plan Dino Viehland wrote: Based upon the feedback from the mailing list here's the 2.6 release plan and list of new features: http://ironpython.codeplex.com/Wiki/View.aspx?title=2.6%20Release%20Pla n Let me know if you have any questions or think there's areas we should include more info on. The profiler API that Curt blogged about isn't on this list. Is it an oversight or has it been dropped? I notice that there is no mention of sys._getframe; does this mean it definitely won't be something we see in 2.6? Shame there is still no sign of the csv module. ;-) Anyway - thanks for the schedule, very helpful. All the best, Michael Foord -- --- --- ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] 2.0.2 Bugs
Michael just brought this up on another thread but I thought I'd make it obvious. Let us know what bugs you particularly want to see fixed in 2.0.2. Nominate them here and we'll collect the list and try to fix as many as possible. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IDLE like functionality
Davy, Thanks.IronTextBox is just what I needed. It needed some minor changes to get running on latest IronPython version but so far looking good. On Wed, Apr 29, 2009 at 2:44 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: There is also IronTextBox which is an IronPython console in a Windows Forms TextBox You will probably need to update it for 2.0.1 but it is probably what you want. http://www.codeproject.com/KB/edit/irontextbox2.aspx Michael Davy On Wed, Apr 29, 2009 at 9:21 AM, Harriv har...@gmail.com wrote: Hi, A beginner's question: Is there a tutorial/demo/sample project to show how embed IDLE like functionality in C# WinForms application? So basically I'd like to add interactive command line to my application, but of course all other features of IDLE (eg debugging, code editors etc) must be left out. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] 2.0.2 Bugs
Dino Viehland wrote:
Michael just brought this up on another thread but I thought I’d make
it obvious.
Let us know what bugs you particularly want to see fixed in 2.0.2.
Nominate them here and we’ll collect the list and try to fix as many
as possible.
Below are the ones I'm aware of that have affected Resolver One or that
I feel are important. :-)
Issue 21715 __file__ incorrect for Pyc compiled modules ( important)
Issue 19656 module name lookup broken
Issue 22235 docstrings
Issue 22239 modules aren't isolated
Issue 21574 import thread safety
Issue 21947 None + ''
Issue 21929 os.listdir('') (A particularly annoying one) - also issue
20603 which is probably the same issue
Issue 21659 Unicode subclasses with non string input in constructor.
(Marked as fixed but probably not in 2.0!)
Issue 21445 IronPython 2.0.1 hang
Issue 21422 Traceback truncation + issue 20051
Issue 20275 str subclasses not treated as strings
Issue 20236 unhelpful help for type
Issue 19724 convert callable to delegate
There are two other issues that might be suitable that I can't find the
numbers for:
Passing '\' to InteractiveConsole.runsource
Repr of SyntaxError messages unchanged when a newline is added (breaks
the code module).
It would be really good to fix the various Pyc bugs - like sys.argv not
being passed through correctly.
Michael
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Using Wing IDE with IronPython - autocomplete for .NET objects (PI file generator)
On Thu, Apr 30, 2009 at 12:43 AM, Jimmie Houchin jlhouc...@gmail.com wrote: This sounds great. I am new to both IronPython, WingIDE and Windows development in general. Interesting to see how much developers want autocomplete! I tried to start adding this to DIE tonight but was struggling with the code editor component. Unfortunately the project looks a little stagnant. Does anyone know of any other good free syntax highlighting .net editor components? Thanks, Davy Mitchell http://code.google.com/p/davysironpythoneditor/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
