Re: [IronPython] clrtype: How to subclass ClrClass?
Hi Lukas, the clrtype fix for http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=26249 is indeed in in 2.6.1. About this Silverlight error, I am not sure. Including the mailing list in case someone else can help. error CS1685 : Warning as error : The predefined type 'System.Runtime.InteropSe rvices.DefaultParameterValueAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\IronPython_Main\Src\Runtime\Microsoft. Scripting.Core\Stubs.cs' Done Building Project C:\IronPython_Main\Src\Runtime\Microsoft.Scripting.Core\ Microsoft.Scripting.Core.csproj (default targets) -- FAILED. From: Lukas Cenovsky [mailto:cenov...@bakalari.cz] Sent: Friday, March 12, 2010 7:47 AM To: Shri Borde Subject: Re: [IronPython] clrtype: How to subclass ClrClass? Unfortunately I am unable to build IronPython for Silverlight. Is it currently broken or do I do something wrong? C:\IronPython_Main\Srcc:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe IronP ython.sln /p:Configuration=Silverlight Release Microsoft (R) Build Engine Version 3.5.30729.4926 [Microsoft .NET Framework, Version 2.0.50727.4927] Copyright (C) Microsoft Corporation 2007. All rights reserved. Build started 12.3.2010 16:40:57. Project C:\IronPython_Main\Src\IronPython.sln on node 0 (default targets). Building solution configuration Silverlight Release|Any CPU. Project C:\IronPython_Main\Src\IronPython.sln (1) is building C:\IronPython_ Main\Src\Runtime\Microsoft.Scripting.Core\Microsoft.Scripting.ExtensionAttribut e.csproj (2) on node 0 (default targets). Project file contains ToolsVersion=4.0, which is not supported by this versio n of MSBuild. Treating the project as if it had ToolsVersion=3.5. PrepareForBuild: Creating directory C:\IronPython_Main\Src\..\Bin\Silverlight Release\. CopyFilesToOutputDirectory: Copying file from obj\Silverlight Release\Microsoft.Scripting.ExtensionAttri bute.dll to C:\IronPython_Main\Src\..\Bin\Silverlight Release\Microsoft.Scr ipting.ExtensionAttribute.dll. Microsoft.Scripting.ExtensionAttribute - C:\IronPython_Main\Bin\Silverlight Release\Microsoft.Scripting.ExtensionAttribute.dll Copying file from obj\Silverlight Release\Microsoft.Scripting.ExtensionAttri bute.pdb to C:\IronPython_Main\Src\..\Bin\Silverlight Release\Microsoft.Scr ipting.ExtensionAttribute.pdb. Done Building Project C:\IronPython_Main\Src\Runtime\Microsoft.Scripting.Core\ Microsoft.Scripting.ExtensionAttribute.csproj (default targets). Project C:\IronPython_Main\Src\IronPython.sln (1) is building C:\IronPython_ Main\Src\Runtime\Microsoft.Scripting.Core\Microsoft.Scripting.Core.csproj (3) on node 0 (default targets). Project file contains ToolsVersion=4.0, which is not supported by this versio n of MSBuild. Treating the project as if it had ToolsVersion=3.5. Project C:\IronPython_Main\Src\Runtime\Microsoft.Scripting.Core\Microsoft.Scri pting.Core.csproj (3) is building C:\IronPython_Main\Src\Runtime\Microsoft.Sc ripting.Core\Microsoft.Scripting.ExtensionAttribute.csproj (2:2) on node 0 (Ge tTargetPath target(s)). Project file contains ToolsVersion=4.0, which is not supported by this versio n of MSBuild. Treating the project as if it had ToolsVersion=3.5. Done Building Project C:\IronPython_Main\Src\Runtime\Microsoft.Scripting.Core\ Microsoft.Scripting.ExtensionAttribute.csproj (GetTargetPath target(s)). Project C:\IronPython_Main\Src\Runtime\Microsoft.Scripting.Core\Microsoft.Scri pting.Core.csproj (3) is building C:\IronPython_Main\Src\Runtime\Microsoft.Sc ripting.Core\Microsoft.Scripting.ExtensionAttribute.csproj (2:3) on node 0 (Ge tNativeManifest target(s)). Project file contains ToolsVersion=4.0, which is not supported by this versio n of MSBuild. Treating the project as if it had ToolsVersion=3.5. Done Building Project C:\IronPython_Main\Src\Runtime\Microsoft.Scripting.Core\ Microsoft.Scripting.ExtensionAttribute.csproj (GetNativeManifest target(s)). error CS1685 : Warning as error : The predefined type 'System.Runtime.InteropSe rvices.DefaultParameterValueAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\IronPython_Main\Src\Runtime\Microsoft. Scripting.Core\Stubs.cs' Done Building Project C:\IronPython_Main\Src\Runtime\Microsoft.Scripting.Core\ Microsoft.Scripting.Core.csproj (default targets) -- FAILED. Done Building Project C:\IronPython_Main\Src\IronPython.sln (default targets) -- FAILED. Build FAILED. C:\IronPython_Main\Src\IronPython.sln (default target) (1) - C:\IronPython_Main\Src\Runtime\Microsoft.Scripting.Core\Microsoft.Scripting.Co re.csproj (default target) (3) - (CoreCompile target) - error CS1685 : Warning as error : The predefined type 'System.Runtime.Interop Services.DefaultParameterValueAttribute' is defined in multiple assemblies in t he global alias; using definition from 'c:\IronPython_Main\Src\Runtime\Microsof t.Scripting.Core\Stubs.cs
Re: [IronPython] clrtype: How to subclass ClrClass?
It is a know bug. I can take a look next week. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Saturday, February 06, 2010 4:10 AM To: Discussion of IronPython Subject: Re: [IronPython] clrtype: How to subclass ClrClass? On 06/02/2010 11:19, Lukas Cenovsky wrote: Hi all, it looks like I cannot subclass a class based on ClrClass metaclass: IronPython 2.6 (2.6.10920.0) on .NET 2.0.50727.4927 Type help, copyright, credits or license for more information. import clr import clrtype class Product(object): ... __metaclass__ = clrtype.ClrClass ... p = Product() print CLR type name: %s % p.GetType().FullName CLR type name: Product class MyProduct(Product): ... pass ... Traceback (most recent call last): File stdin, line 1, in module KeyError: The given key was not present in the dictionary. Is it a bug or am I doing something wrong? Thanks. Hehe, I ran into this a couple of days ago on Silverlight as well. All the best, Michael -- -- Lukáš ___ 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 READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Users mailing list Users@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] Calling a System DLL In IronPython?
Its in Samples.zip on http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12482. There have been a few bug fixes since that are not in Samples.zip, but it does not affect pinvoke. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Sunday, January 24, 2010 4:19 AM To: Discussion of IronPython Cc: users@lists.ironpython.com Subject: Re: [IronPython] Calling a System DLL In IronPython? For ctypes you should use the documentation that is part of the Python documentation. For PInvoke the references will be mainly for C#. Does anyone have examples of using PInvoke with clrtype and IronPython 2.6? Michael -- http://www.ironpythoninaction.com On 24 Jan 2010, at 03:24, David McWright david.mcwri...@usbfmi.com wrote: Is there a reference somewhere for PInvoke or ctypes in IP? TIA, David On Jan 23, 7:31 pm, Michael Foord fuzzy...@voidspace.org.uk wrote: On 24/01/2010 00:19, Andrew Evans wrote: I am trying to call user32.dll into IronPython how do I do this? Do I use clr.AddReference, that doesn't seem to do it. clr.AddReference only works for .NET assemblies. user32.dll is not a .NET assembly. To use it you will either need PInvoke or ctypes that comes with IronPython 2.6. PInvoke relies on .NET attributes. It used to be the case that you couldn't use these directly with IronPython but needed a simple C# wrapper. The following article shows how to call into user32.dll using a C# wrapper: http://www.voidspace.org.uk/ironpython/winforms/part10.shtml Alternatively you can try clrtype.py that comes with IronPython 2.6. All the best, Michael Foord Suggestions ___ Users mailing list us...@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com --http://www.ironpythoninaction.com/http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (BOGUS AGREEMENTS) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Users mailing list us...@lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/ users-ironpython.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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Calling a System DLL In IronPython?
Good idea (for all other samples too). Will look into it. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Monday, January 25, 2010 2:00 PM To: Discussion of IronPython Subject: Re: [IronPython] Calling a System DLL In IronPython? On 25/01/2010 21:23, Shri Borde wrote: Its in Samples.zip on http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12482. There have been a few bug fixes since that are not in Samples.zip, but it does not affect pinvoke. Great - thanks. For what it's worth it is worth running a tool like pyflakes over clrtype.py. I'm using a version that is possibly slightly outdated in a Silverlight project and pyflakes gives several warnings on clrtype.py (including a warning about an incorrectly constructed assert): modules/clrtype.py:21: 'Char' imported but unused modules/clrtype.py:21: 'Boolean' imported but unused modules/clrtype.py:27: 'NameType' imported but unused modules/clrtype.py:28: 'ReflectedProperty' imported but unused modules/clrtype.py:182: local variable 'p' is assigned to but never used modules/clrtype.py:354: local variable 'p' is assigned to but never used (I have already fixed the assert manually I believe.) All the best, Michael -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Sunday, January 24, 2010 4:19 AM To: Discussion of IronPython Cc: users@lists.ironpython.com Subject: Re: [IronPython] Calling a System DLL In IronPython? For ctypes you should use the documentation that is part of the Python documentation. For PInvoke the references will be mainly for C#. Does anyone have examples of using PInvoke with clrtype and IronPython 2.6? Michael -- http://www.ironpythoninaction.com On 24 Jan 2010, at 03:24, David McWrightdavid.mcwri...@usbfmi.com wrote: Is there a reference somewhere for PInvoke or ctypes in IP? TIA, David On Jan 23, 7:31 pm, Michael Foordfuzzy...@voidspace.org.uk wrote: On 24/01/2010 00:19, Andrew Evans wrote: I am trying to call user32.dll into IronPython how do I do this? Do I use clr.AddReference, that doesn't seem to do it. clr.AddReference only works for .NET assemblies. user32.dll is not a .NET assembly. To use it you will either need PInvoke or ctypes that comes with IronPython 2.6. PInvoke relies on .NET attributes. It used to be the case that you couldn't use these directly with IronPython but needed a simple C# wrapper. The following article shows how to call into user32.dll using a C# wrapper: http://www.voidspace.org.uk/ironpython/winforms/part10.shtml Alternatively you can try clrtype.py that comes with IronPython 2.6. All the best, Michael Foord Suggestions ___ Users mailing list us...@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com --http://www.ironpythoninaction.com/http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (BOGUS AGREEMENTS) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Users mailing list us...@lists.ironpython.comhttp://lists.ironpython.com/listinfo.cgi/ users-ironpython.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 ___ 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 READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (BOGUS AGREEMENTS) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without
Re: [IronPython] .NET attributes for methods
I can help you create a property. And I can help you get it to work with your
decorators (you can check if the name property exposes your @notify_property
wrapper methods or not, and presumably that works). Beyond that, you are on
your own :)
I would try calling the property methods to make sure they are accessible.
Something like this. If that works, I am not sure what Silverlight needs to
make databinding happy.
props = a.root.listbox1.Items[0].GetType().GetProperties()
prop = props[0]
prop.GetGetMethod.Invoke(a, None) # call using Reflection
About the SystemError: Application code cannot access
System.AppDomain.get_CurrentDomain() using Reflection. error when defining
interfaces, it could be worked around. We need to call
AppDomain.DefineDynamicAssembly, and IronPython itself does do this. So its
just a question of figuring out the right way to access an AppDomain instance.
Will look into it, but I doubt it will help you with data binding.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky
Sent: Friday, November 13, 2009 5:42 AM
To: Discussion of IronPython
Subject: Re: [IronPython] .NET attributes for methods
This looks very promising but I cannot make it work. I have changed product.py
in DevHawk's example to:
#from clrtypeold import ClrMetaclass
import clrtype
class Product(object):
#__metaclass__ = ClrMetaclass
__metaclass__ = clrtype.ClrClass
_clrnamespace = DevHawk.IronPython.ClrTypeSeries
#_clrproperties = {
#name:str,
#cost:float,
#quantity:int,
#}
def __init__(self, name, cost, quantity):
self.name = name
self.cost = cost
self.quantity = quantity
def calc_total(self):
return self.cost * self.quantity
@property
@clrtype.accepts()
@clrtype.returns(str)
def name(self):
return self._name
@name.setter
@clrtype.accepts(str)
@clrtype.returns()
def name(self, value):
self._name = value
When I run it I don't see any items in the listbox. When I check the name, it
is a property:
py a.root.listbox1.Items[0]
= Product object at 0x002B
py a.root.listbox1.Items[0].GetType().GetProperties()
= Array[PropertyInfo]((System.Reflection.RuntimePropertyInfo object at
0x002C [System.String name]))
Whe I used the old clrtype with _clrproperties = {'name': str, ...}, it worked.
--
-- Lukáš
Shri Borde wrote:
Here is an updated version of clrtype.py that uses @property +
@clrtype.accepts/@clrtype.returns to indicate a CLR property, instead of using
_clrproperties. I think its more Pythonic in general, but also you should be
able to modify @notify_property to work with it.
Note that notify_property won't just work. You will have to change it to
propagate the func_name, arg_types, and return_type properties from the old
getter/setter function objects to the new getter/setter function objects since
these values are used by clrtype to generate the CLR members. Something like
this:
class notify_property(property):
def propagate_attributes(old_function, new_function):
new_function.func_name = old_function.func_name
new_function.arg_types = old_function.arg_types
new_function.return_type = old_function.return_type
def __init__(self, getter):
def newgetter(slf):
try:
return getter(slf)
except AttributeError:
return None
propagate_attributes(getter, newgetter)
super(notify_property, self).__init__(newgetter)
def setter(self, setter):
def newsetter(slf, newvalue):
oldvalue = self.fget(slf)
if oldvalue != newvalue:
setter(slf, newvalue)
slf.OnPropertyChanged(setter.__name__)
propagate_attributes(setter, newsetter)
return property(
fget=self.fget,
fset=newsetter,
fdel=self.fdel,
doc=self.__doc__)
From: Lukas Cenovsky [mailto:cenov...@bakalari.cz]
Sent: Thursday, November 12, 2009 11:01 AM
To: Shri Borde
Subject: Re: [IronPython] .NET attributes for methods
Shri Borde wrote:
So the new clrtype.py still works - cool!
Yep ;-)
I am not an expert on data binding, so I don't have any suggestions. Why do
you say that the decorator approach will not work with Silverlight? Does
@notifiy_property from
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-in-ironpython.html
use any feature not available in Silverlight?
It does not (as far as I know because it is pure IronPython). But
@notify_property does not work with clrtypes:
class ViewModel(NotifyPropertyChangedBase):
__metaclass__ = clrtype.ClrMetaclass
_clrnamespace = Cenda.ViewModel
_clrproperties = {'size': str}
def __init__(self):
super(ViewModel, self).__init__()
# must be string to two-way binding work correctly
self.size = '10
Re: [IronPython] .NET attributes for methods
So the new clrtype.py still works - cool!
I am not an expert on data binding, so I don't have any suggestions. Why do you
say that the decorator approach will not work with Silverlight? Does
@notifiy_property from
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-in-ironpython.html
use any feature not available in Silverlight?
From: Lukas Cenovsky [mailto:cenov...@bakalari.cz]
Sent: Thursday, November 12, 2009 8:09 AM
To: Shri Borde
Subject: Re: [IronPython] .NET attributes for methods
Thanks, that works!
What do you think would be the best approach to create notifiable properties
for Silverlight? I did it for WPF (via decorators:
http://gui-at.blogspot.com/2009/11/inotifypropertychanged-in-ironpython.html)
but it seems to me it won't be possible to do it similarly for Silverlight...
--
-- Lukáš
Shri Borde wrote:
Can you use _clrproperties instead of _clrfields? DevHawk's same created a
field and a property even when you just used _clrfields. I don't do that
anymore. So you will need to use _clrproperties to get properties, which SL
must use for data binding.
From:
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky
Sent: Wednesday, November 11, 2009 2:37 AM
To: Discussion of IronPython
Subject: Re: [IronPython] .NET attributes for methods
I did change __metaclass__ to ClrMetaclass. See the attached source I use for
testing - the only difference is to comment/uncomment appropriate part in
product.py.
The outputs look the same, there are no visible exceptions:
DevHawk:
py a.root.FindName('listbox1').ItemsSource[0].GetType().GetFields()
= Array[FieldInfo]((System.Reflection.RtFieldInfo object at
0x002B [Double cost],
System.Reflection.RtFieldInfo object at 0x002C [Int32 quantity],
System.Reflection.RtFieldInfo object at 0x002D [System.String
name],
System.Reflection.RtFieldInfo object at 0x002E
[IronPython.Runtime.Types.PythonType .class],
System.Reflection.RtFieldInfo object at 0x002F
[IronPython.Runtime.PythonDictionary .dict],
System.Reflection.RtFieldInfo object at 0x0030 [System.Object[]
.slots_and_weakref]))
Shri:
py a.root.FindName('listbox1').ItemsSource[0].GetType().GetFields()
= Array[FieldInfo]((System.Reflection.RtFieldInfo object at
0x002B [Double cost],
System.Reflection.RtFieldInfo object at 0x002C [Int32 quantity],
System.Reflection.RtFieldInfo object at 0x002D [System.String
name],
System.Reflection.RtFieldInfo object at 0x002E
[IronPython.Runtime.Types.PythonType .class],
System.Reflection.RtFieldInfo object at 0x002F
[IronPython.Runtime.PythonDictionary .dict],
System.Reflection.RtFieldInfo object at 0x0030 [System.Object[]
.slots_and_weakref]))
--
-- Lukáš
Shri Borde wrote:
Note that you will have to set __metaclass__ to ClrMetaclass, not
ClrTypeMetaclass as in DevHawk's sample. I had changed the name of the type.
The old name will cause a NameError, but maybe SL is hiding exceptions. Can you
do o.GetType().GetFields() and display that on the page to inspect the object
and also make sure that no exceptions were thrown?
From:
users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky
Sent: Tuesday, November 10, 2009 2:59 PM
To: Discussion of IronPython
Subject: Re: [IronPython] .NET attributes for methods
I have just found that the Silverlight binding does not work with this version
of clrtype and/or IronPython 2.6RC2.
I used DevHawk demo [1] and after I added reference to Microsoft.Dynamic in
clrtypemetaclass.py it worked flawlessly. But when I switch to your version, no
items show in the listbox.
By the way - I have seen a commit message you have added support for interfaces
- nice! ;-)
--
-- Lukáš
[1]
http://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/^_^_clrtype^_^_/SL%20databinding%20demo.ziphttp://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/%5E_%5E_clrtype%5E_%5E_/SL%20databinding%20demo.zip
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] .NET attributes for methods
Note that you will have to set __metaclass__ to ClrMetaclass, not ClrTypeMetaclass as in DevHawk's sample. I had changed the name of the type. The old name will cause a NameError, but maybe SL is hiding exceptions. Can you do o.GetType().GetFields() and display that on the page to inspect the object and also make sure that no exceptions were thrown? From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Tuesday, November 10, 2009 2:59 PM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes for methods I have just found that the Silverlight binding does not work with this version of clrtype and/or IronPython 2.6RC2. I used DevHawk demo [1] and after I added reference to Microsoft.Dynamic in clrtypemetaclass.py it worked flawlessly. But when I switch to your version, no items show in the listbox. By the way - I have seen a commit message you have added support for interfaces - nice! ;-) -- -- Lukáš [1] http://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/^_^_clrtype^_^_/SL%20databinding%20demo.ziphttp://cid-0d9bc809858885a4.skydrive.live.com/self.aspx/DevHawk%20Content/IronPython%20Stuff/%5E_%5E_clrtype%5E_%5E_/SL%20databinding%20demo.zip Shri Borde wrote: The following files extend DevHawk's blog and adds support for typed methods with attributes. It will be available as part of the samples released with the 2.6 RTM (over the next month). Do let us know if it works for you. Also, I would be curious to know what scenario you need method attributes for (other than DllImport for pinvokes)... -Original Message- From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Thursday, October 22, 2009 10:37 AM To: Discussion of IronPython Subject: [IronPython] .NET attributes for methods Hi, I have read all DewHawk blogposts about .Net attributes in IronPython via __clrtype__ metaclass (http://devhawk.net/CategoryView,category,__clrtype__.aspx). He describes how to add attributes to classes but not to methods. Is there any example how to add attributes to a method. It looks like method generation is necessary (like for getter and setter or in http://www.voidspace.org.uk/python/weblog/arch_d7_2007_03_10.shtml#e659) but this is kind of deep magic for me... Thanks. -- -- Lukáš ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto: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] Safe execution of python scripts on my .net application
http://www.dev102.com/2008/03/22/3-ways-to-run-nunit-from-visual-studio/ has some info about test projects and appbase problems. You can also use fuslogvw (http://msdn.microsoft.com/en-us/library/e74a18c4(VS.71).aspx) to see why Microsoft.Scripting.dll is failing to load. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Tuesday, November 03, 2009 1:52 PM To: Discussion of IronPython Subject: Re: [IronPython] Safe execution of python scripts on my .net application Test projects are weird and somehow you don't end up inheriting the application base. This seems to work though: AppDomainSetup setup = new AppDomainSetup(); setup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory; AppDomain aSandboxedDomain = AppDomain.CreateDomain(Sandboxed Domain, null, setup); ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); ScriptSource source = engine.CreateScriptSourceFromString(2+2); ScriptScope scope = engine.CreateScope(); Console.WriteLine(source.Execute(scope)); From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Nicolás Buttarelli Sent: Tuesday, November 03, 2009 1:30 PM To: Discussion of IronPython Subject: Re: [IronPython] Safe execution of python scripts on my .net application I have create a new Test Project and an Unit Test class in order to test the following code inside: AppDomain aSandboxedDomain = AppDomain.CreateDomain(Sandboxed Domain); ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); ScriptSource source = engine.CreateScriptSourceFromString(pythonScript); ScriptScope scope = engine.CreateScope(); source.Execute(scope); I have add the references: - IronPython - Microsoft.Scripting - Microsoft.ScriptingCore But it still not working and throwing the same System.Runtime.Serialization.SerializationException: Type is not resolved for member 'Microsoft.Scripting.Hosting.ScriptRuntimeSetup,Microsoft.Scripting. Any ideas? 2009/11/3 Nicolás Buttarelli nbuttare...@gmail.commailto:nbuttare...@gmail.com Thanks Shri, I will try. In addition, I found this open issue: http://dlr.codeplex.com/WorkItem/View.aspx?WorkItemId=2816. I think that it is related. On Tue, Nov 3, 2009 at 9:29 PM, Shri Borde shri.bo...@microsoft.commailto:shri.bo...@microsoft.com wrote: I think this happens if the new appdomain cannot load the required assembly. By default, the new appdomain should inherit its BaseDirectory property from the creating domain and should be able to load Microsoft.Scripting.dll. Is your exe and all the dlls in the same folder? If not, can you try to put all assemblies in the same folder (or in the GAC) to see if it works? If that works, you can then figure out how to configure the new appdomain such that it can load Microsoft.Scripting.dll. There may be some setting in AppDomainSetup, or you could hook the AssemblyResolve event... 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 Nicolás Buttarelli Sent: Tuesday, November 03, 2009 12:08 PM To: Discussion of IronPython Subject: Re: [IronPython] Safe execution of python scripts on my .net application Hi again, thanks for your clear response. I was trying to do what you proposed but it is not working. I am receiving an exception: Test method CadworX3WCFRestTest.IronPython.SafeScriptExecutionTest.writingAFileTest threw exception: System.Runtime.Serialization.SerializationException: Type is not resolved for member 'Microsoft.Scripting.Hosting.ScriptRuntimeSetup,Microsoft.Scripting, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.. I tried to find a solution but I couldn't. This is the minimal code that I am running to get this exception (I have removed all the security stuff but apparently that does not resolve the problem): AppDomain aSandboxedDomain = AppDomain.CreateDomain(Sandboxed Domain); ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); ScriptSource source = engine.CreateScriptSourceFromString(pythonScript); SriptScope scope = engine.CreateScope(); source.Execute(scope); The exception is thronged in this line: ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); Do you have any idea which could be the problem? Thanks again, Nicolas On Mon, Nov 2, 2009 at 10:25 PM, Dino Viehland di...@microsoft.commailto:di...@microsoft.com wrote: Assuming the app domain is setup properly then there's no way for the Python code to elevate permissions (modulo CLR security bugs which are few and far between). This is because IronPython its self is 100% security transparent and does not affect any security decisions or assert any form of trust - so it's all up to the CLR to limit permissions. So for example while you can access
Re: [IronPython] Safe execution of python scripts on my .net application
I think this happens if the new appdomain cannot load the required assembly. By default, the new appdomain should inherit its BaseDirectory property from the creating domain and should be able to load Microsoft.Scripting.dll. Is your exe and all the dlls in the same folder? If not, can you try to put all assemblies in the same folder (or in the GAC) to see if it works? If that works, you can then figure out how to configure the new appdomain such that it can load Microsoft.Scripting.dll. There may be some setting in AppDomainSetup, or you could hook the AssemblyResolve event... From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Nicolás Buttarelli Sent: Tuesday, November 03, 2009 12:08 PM To: Discussion of IronPython Subject: Re: [IronPython] Safe execution of python scripts on my .net application Hi again, thanks for your clear response. I was trying to do what you proposed but it is not working. I am receiving an exception: Test method CadworX3WCFRestTest.IronPython.SafeScriptExecutionTest.writingAFileTest threw exception: System.Runtime.Serialization.SerializationException: Type is not resolved for member 'Microsoft.Scripting.Hosting.ScriptRuntimeSetup,Microsoft.Scripting, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.. I tried to find a solution but I couldn't. This is the minimal code that I am running to get this exception (I have removed all the security stuff but apparently that does not resolve the problem): AppDomain aSandboxedDomain = AppDomain.CreateDomain(Sandboxed Domain); ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); ScriptSource source = engine.CreateScriptSourceFromString(pythonScript); SriptScope scope = engine.CreateScope(); source.Execute(scope); The exception is thronged in this line: ScriptEngine engine = Python.CreateEngine(aSandboxedDomain); Do you have any idea which could be the problem? Thanks again, Nicolas On Mon, Nov 2, 2009 at 10:25 PM, Dino Viehland di...@microsoft.commailto:di...@microsoft.com wrote: Assuming the app domain is setup properly then there's no way for the Python code to elevate permissions (modulo CLR security bugs which are few and far between). This is because IronPython its self is 100% security transparent and does not affect any security decisions or assert any form of trust - so it's all up to the CLR to limit permissions. So for example while you can access the file object, or import ctypes, or call various other Python APIs which would require trust you'll get a security exception from the CLR when you don't have permissions to do something. For more complex scenarios you might also have an object model which you expose to the application and inject in via its scope. Once you've done that you'll want to make sure that the object model is also secure. 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 Nicolás Buttarelli Sent: Monday, November 02, 2009 1:20 PM To: Discussion of IronPython Subject: Re: [IronPython] Safe execution of python scripts on my .net application Thanks for your response. But what happens with the python code? Does not exist a way to write some scripts that can do some damage to my app, the server, the database, etc? Thanks again, Nicolas On Mon, Nov 2, 2009 at 9:41 PM, Dino Viehland di...@microsoft.commailto:di...@microsoft.com wrote: After creating your app domain you can do: ScriptEngine engine = Python.CreateEngine(someAppDomain); And then the rest of your code should work as it's written. 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 Nicolás Buttarelli Sent: Monday, November 02, 2009 12:39 PM To: users@lists.ironpython.commailto:users@lists.ironpython.com Subject: [IronPython] Safe execution of python scripts on my .net application Sorry, I don't know if my previous message have arrived. So, here it is: Hello all, I am starting with python and I would like to add to my web application some web services. This services will allow the different clients of my application to execute some python scripts. I would like to know if someone did this before and how can I do this in a secure way. I mean, how can I do to restrict the environment where the scripts will be executed. In .net I can do this using the AppDoman and setting the permission set. AppDomain.CreateDomain( string friendlyName, Evidence securityInfo, AppDomainSetup info, PermissionSet grantSet, params StrongName[] fullTrustAssemblies); Is there a way to do the same with my python scripts? I am running them using this: ScriptEngine engine = Python.CreateEngine();
Re: [IronPython] .NET attributes for methods
It should be possible. However, note that you create the .dll using clr.GetSubclassedTypes (and clr.CompileSubclassedTypes) which requires you to run your application with all the scenarios you care about. You can't just run a simple command line like csc.exe foo.cs and get a dll. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Monday, November 02, 2009 9:29 AM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes for methods I was thinking about this... Does ir mean that (after adding such support to clrtype) and building a .dll from the interface class, this class can be used from c#? -- -- Lukáš Shri Borde wrote: The clrtype module could be extended to make it possible to declare CLR interfaces in Python code. Something like: class IFoo(object): __metaclass__ = ClrType.ClrInterface # Proposed way to indicate an interface @clrtype.accepts(int, str) @clrtype.returns(int) @clrtype.attribute(OperationContractAttribute)() def foo(i, s):raise RuntimeError(this should not get called) This does not work today... From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Friday, October 30, 2009 10:41 AM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes for methods Thanks. I wanted to implement WCF service in pure Ironpython but I overlooked the [OperationContract] method attribute is used in the interface declaration. Anyway, thanks to class attributes it is now possible to implement the WCF service in IronPython and have only the interface done in C#. See my blog post: http://gui-at.blogspot.com/2009/10/wcf-service-in-ironpython.html DllImport is good to have too - I can get rid of of my Win32API.dll when simulating user's inputhttp://gui-at.blogspot.com/2008/07/simulate-users-input.html :-) -- -- Lukáš Shri Borde wrote: The following files extend DevHawk's blog and adds support for typed methods with attributes. It will be available as part of the samples released with the 2.6 RTM (over the next month). Do let us know if it works for you. Also, I would be curious to know what scenario you need method attributes for (other than DllImport for pinvokes)... -Original Message- From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Thursday, October 22, 2009 10:37 AM To: Discussion of IronPython Subject: [IronPython] .NET attributes for methods Hi, I have read all DewHawk blogposts about .Net attributes in IronPython via __clrtype__ metaclass (http://devhawk.net/CategoryView,category,__clrtype__.aspx). He describes how to add attributes to classes but not to methods. Is there any example how to add attributes to a method. It looks like method generation is necessary (like for getter and setter or in http://www.voidspace.org.uk/python/weblog/arch_d7_2007_03_10.shtml#e659) but this is kind of deep magic for me... Thanks. -- -- Lukáš ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto: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] .NET attributes for methods
The clrtype module could be extended to make it possible to declare CLR interfaces in Python code. Something like: class IFoo(object): __metaclass__ = ClrType.ClrInterface # Proposed way to indicate an interface @clrtype.accepts(int, str) @clrtype.returns(int) @clrtype.attribute(OperationContractAttribute)() def foo(i, s):raise RuntimeError(this should not get called) This does not work today... From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Friday, October 30, 2009 10:41 AM To: Discussion of IronPython Subject: Re: [IronPython] .NET attributes for methods Thanks. I wanted to implement WCF service in pure Ironpython but I overlooked the [OperationContract] method attribute is used in the interface declaration. Anyway, thanks to class attributes it is now possible to implement the WCF service in IronPython and have only the interface done in C#. See my blog post: http://gui-at.blogspot.com/2009/10/wcf-service-in-ironpython.html DllImport is good to have too - I can get rid of of my Win32API.dll when simulating user's inputhttp://gui-at.blogspot.com/2008/07/simulate-users-input.html :-) -- -- Lukáš Shri Borde wrote: The following files extend DevHawk's blog and adds support for typed methods with attributes. It will be available as part of the samples released with the 2.6 RTM (over the next month). Do let us know if it works for you. Also, I would be curious to know what scenario you need method attributes for (other than DllImport for pinvokes)... -Original Message- From: users-boun...@lists.ironpython.commailto:users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Lukas Cenovsky Sent: Thursday, October 22, 2009 10:37 AM To: Discussion of IronPython Subject: [IronPython] .NET attributes for methods Hi, I have read all DewHawk blogposts about .Net attributes in IronPython via __clrtype__ metaclass (http://devhawk.net/CategoryView,category,__clrtype__.aspx). He describes how to add attributes to classes but not to methods. Is there any example how to add attributes to a method. It looks like method generation is necessary (like for getter and setter or in http://www.voidspace.org.uk/python/weblog/arch_d7_2007_03_10.shtml#e659) but this is kind of deep magic for me... Thanks. -- -- Lukáš ___ Users mailing list Users@lists.ironpython.commailto:Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.commailto: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] Overriding .NET methods within IronPython
See the section on Overriding methods in http://ironpython.codeplex.com/SourceControl/changeset/view/60398#1011839 (IronPython_Main\Doc\dotnet-integration.rst) for more details on overriding, like dealing with ref params. We are working on making the info easily accessible, but for now, you can browse the content from the rst file. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Brian Curtin Sent: Friday, October 23, 2009 11:53 AM To: Discussion of IronPython Subject: Re: [IronPython] Overriding .NET methods within IronPython I'm not sure what I was doing wrong when this clearly simpler way wasn't working, but this pretty much answers my question: do this - Form.OnLoad(self, evt_args) Sorry for the noise. On Fri, Oct 23, 2009 at 13:45, Brian Curtin brian.cur...@gmail.commailto:brian.cur...@gmail.com wrote: Hey list, I think I got this right, and it seems to work, but I just feel like there is probably a better way to override a method in IP. Some time spent googling doesn't bring anything up except for IP/C# code examples containing the override keyword. For example, I want to override the Form class' OnLoad method, so I wrote a decorator to do so. class frm(Form): def __init__(self): Form.__init__(self) def override(method): def inner(*args): base = super(Form, args[0]) #args[0] is frm instance base_method = getattr(base.__thisclass__, method.__name__) method(*args) #call our method first return base_method(*args) return inner @override def OnLoad(self, evt_args): print evt_args It doesn't do anything snazzy - just prints out the EventArgs, then calls the base class Form.OnLoad. Any thoughts? Brian ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Reflection.Emit from IronPython: What is the equivalent of typeof() in C# ?
You can also just use the type like System.String to avoid having to create
an instance of the type.
import System
import clr
clr.GetClrType(System.String)
System.RuntimeType object at 0x002B [System.String]
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dave Fugate
Sent: Thursday, August 06, 2009 2:07 PM
To: rob...@smallshire.org.uk; Discussion of IronPython; 'Michael Foord'
Subject: Re: [IronPython] Reflection.Emit from IronPython: What is the
equivalent of typeof() in C# ?
Try:
clr.GetClrType(type(''))
David Fugate
Microsoft - IronPython
http://knowbody.livejournal.com
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Robert Smallshire
Sent: Thursday, August 06, 2009 1:53 PM
To: 'Michael Foord'; 'Discussion of IronPython'
Subject: Re: [IronPython] Reflection.Emit from IronPython: What is the
equivalent of typeof() in C# ?
Hi Michael,
I'm afraid not:
clr.GetClrType('')
TypeError: expected Type, got str
My hopes were momentarily raised when I discovered that your otherwise very
comprehensive book mentions typeof in the index (page 398) - but then I
found that you only use it from C#.
Cheers,
Rob
clr.GetClrType('') ? (on an instance of a string)
Michael
Robert Smallshire wrote:
Hello,
I'm attempting to drive the Reflection.Emit API from
IronPython. In C#
typical Reflection.Emit use makes use typeof(...) facility
in C#, to
enable the determination of types without needing an
instance of that
type.
For example, to create an array of .NET CTS Strings in IL
from C# one
might
do:
generator.Emit(OpCodes.Newarr, typeof(string));
where the second argument to Emit is the element type of the array.
I've tried various alternatives from IronPython, including
generator.Emit(OpCodes.Newarr, System.Type.GetType('System.String'))
generator.Emit(OpCodes.Newarr, str().GetType())
generator.Emit(OpCodes.Newarr, System.String().GetType())
generator.Emit(OpCodes.Newarr, clr.GetClrType(System.String))
however, all of these result in RuntimeType[] rather than
String[] in
the generated CIL.
How do I get typeof(System.String) from IronPython?
Rob
Robert Smallshire
rob...@smallshire.org.uk
http://smallshire.org.uk/
Currently in Norway (UTC +2 hours)
___
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
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Ironpython COM vs Jscript.Net COM
IronPython 2.0 supports dynamic COM servers. See
http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michel Claveau
Sent: Wednesday, June 17, 2009 7:22 AM
To: users@lists.ironpython.com
Subject: [IronPython] Ironpython COM vs Jscript.Net COM
Hi!
IronPython has poor support of COM techno. In particular, IP can not use
dynamic COM servers (perhaps because they do not have TLB?).
Now, cPython is good to create dynamic COM servers (see Python Programming
on Win32, page 219 +).
Thus, ironPython is bad, to use the COM servers made with cPython.
But...
Recently, I had a look on Jscript.Net (NOT managed_JScript).
I found that this language uses dynamic type (as Python), and can use
dynamic COM servers! (and without DLR!!!)
Example:
var pd = new ActiveXObject(Ponxd.Mci);
var result = pd.myfuncsinverse('AABBCC');
IronPython could use the mechanics of JScript.Net, for COM servers?It
would solve many problems.
@+
--
Michel Claveau
(sorry for my bad English)
___
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] Response may be slow from the IronPython team...
Dino is OOF through Monday, and a few others are attending some talks. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Thursday, June 04, 2009 12:30 PM To: Discussion of IronPython Subject: Re: [IronPython] CallTarget0 problem Kent Johnson wrote: Hi, I am an IPy newbie, trying to run example 7.17 from IronPython in Action. It includes the code delegate = CallTarget0(something.form.Close) something.form.Invoke(delegate) were something.form is a Windows.Forms.Form object. The first line above gives this error: Traceback (most recent call last): File C:\Project\MangoTest\src\SmokeTest.py, line 43, in C:\Project\MangoTest\src\SmokeTest.py File mscorlib, line unknown, in CreateDelegate ValueError: Error binding to target method. A while ago there were changes to CallTarget0 that made it incompatible with .NET methods that have a void return signature. Dino told me he would change it back so it would work again, but I guess that didn't happen... If I change the first line to delegate = CallTarget0(lambda: something.form.Close()) it works fine. This is the correct change to fix it. Does the argument to CallTarget0() have to be a Python function? Or, what is going on here? No - but it is methods with a void return signature that are the issue. Michael -- 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] Urgent : Unable to open MS Word file from Python
Try using this workaround. import clr r = clr.Reference[str]() r.Value = source_filename word_application.Documents.Open(r) You should not have to do this with IPy 2.6, and probably even with 2.0. Using a str directly works for me. What version of IronPython are you using? I think the workaround might have been needed with IPy 1.X. See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx for some details about using COM from IPy. Thanks, Shri From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Sivaguru Perambalam Sent: Wednesday, June 03, 2009 1:36 PM To: users@lists.ironpython.com Subject: [IronPython] Urgent : Unable to open MS Word file from Python Hello, I have written this small script, which is (part of an application that is) supposed to open a MS Word Document and manipulate it (do a search and replace) . I am getting a weird exception when I try to run the script. It says TypeError: expected clr.Reference, got str for the line where I try to open the file. But the same script runs fine on a colleague's computer . I couldn't figure out what his computer has that mine doesn't.So I thought of asking what are the necessary things (libs, dlls) that are needed to Open/Work on MS Word File from Iron Python. MS Excel interaction works fine in my computer though. I have Office 07, MS Visual Studio 05, .NET Framework 2.0 installed in my computer. I have also verified that Microsoft.Office.Interop.Word version 12.0.0.0 is found registered in the Assembly Cache. This issue has become a Show-stopper for the Application I am working on. So, any helpful suggestions or directions would mean a lot ! Thanks !! Script : import clr import System clr.AddReference(Microsoft.Office.Interop.Word) import Microsoft.Office.Interop.Word as Word source_filename = 'C:\Sample_Report.doc' destination_filename = 'c:\Validation Report.doc' missing = System.Type.Missing replaceAll = Word.WdReplace.wdReplaceAll # Open the Report Template MSWord File word_application = Word.ApplicationClass() word_application.Visible = False document = word_application.Documents.Open(source_filename) print 'opened microsoft word' document.SaveAs(destination_filename) document.Close() document = None word_application.Quit() word_application = None Error Message : C:\Program Files\DotQuestLite\Bin\ipy.exe word.py Traceback (most recent call last): File C:\Documents and Settings\sp19206\Desktop\word.py, line 17, in Initialize TypeError: expected clr.Reference, got str Process Exit Code: 1 Time Taken: 00:07 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] can anyone help me with COM access in ironpython?
Have you tried import System followed by System.Activator.CreateInstance(System.Type.GetTypeFromProgID(QBXMLRP2.RequestProcessor)? This should more closely resemble the behavior of the pywin32 code of win32com.client.Dispatch(QBXMLRP2.RequestProcessor). See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx for some info. Thanks, Shri From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland Sent: Friday, May 15, 2009 4:35 PM To: Discussion of IronPython Subject: Re: [IronPython] can anyone help me with COM access in ironpython? [note my knowledge of this area is fuzzy at best but this is my understanding. Maybe someone from the team can explain this better or give more accurate information if I get anything wrong]. The reason why these are so different is to date IronPython has basically gotten it's COM interop support for free from one of two locations: 1) The CLR providing interop assemblies to talk to COM objects (in 1.x) 2) DLR IDispatch support in IronPython 2.0 In 2.0 there's a command line option which gives you a hybrid of these options: -X:PreferComInteropAssembly. Ok, so that gives us two different modes...In 1.x, or when you use this option, you generally get the normal .NET COM interop - so if you want documentation on it you can go and look at normal .NET COM interop docs. In mode 2 we're using the DLR which is directly talking to COM objects which implement IDispatch. This is like class VB or VBA COM interop. It's a little bit more limited in what it can do because the objects need to implement IDispatch. So again if you wanted documentation you'd generally look at how to use these objects from classic VB/VBA and just follow those instructions. Obviously we weren't very confident about the DLR IDispatch support when we shipped 2.0 which is the reason why we added the -X:PreferComInteropAssembly command line option. The DLR team has spent more time improving the COM interop support and validating that it's compatible w/ old VB/VBA semantics since then and we're more confident that it'll be quite usable for 2.6. But neither option is really designed to be code compatible w/ pywin32. This is something we could certainly push on in the future and I'd encourage you to open a bug on IronPython.CodePlex.com (and others to vote on it) if COM compat w/ CPython is important. From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Luke Graybill Sent: Friday, May 15, 2009 2:40 PM To: users@lists.ironpython.com Subject: [IronPython] can anyone help me with COM access in ironpython? I've got a working example using the pywin32 extensions, which I am trying to duplicate in IronPython, but I'm encountering quite a number of strange situations. I can't seem to find any real documentation for IronPython, either, so I figure this list is my last place to go before I ditch IronPython and just use pywin32 instead. Anyway, here is the pywin32 code: http://dpaste.org/aZpE/ The crucial part there is where the COM object (QBXMLRP2.RequestProcessor) is used. IronPython does seem to allow me to use the same object for some reason, forcing me to select a different one, as you'll see here: http://dpaste.org/rIzF/ What am I missing here? Specifically, 1) Why does the exact same COM object function differently (and ultimately fail) when used through IronPython? 2) Why are different methods exposed on the COM object through IronPython's clr module, than when the COM object is used through pywin32's client dispatch? 3) Why do I need to refer the the COM object as Interop.QBXMLRP2 in IronPython, but simply as QBXMLRP2 in pywin32? I'm missing something fundamental here, please enlighten me! :) Thanks! -- Visit me @ http://killarny.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IronPython in Action Out!
Congratulations! This is very exciting! -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Friday, April 10, 2009 11:17 AM To: Discussion of IronPython Subject: [IronPython] IronPython in Action Out! Hello all, *Finally* IronPython in Action is out. This is the first English language book on IronPython and is now in stock with Manning and Amazon.com and on the Safari bookshelf. You can get all the details from: * http://www.ironpythoninaction.com It covers a whole range of topics, with introductions to Python and .NET, using various Python libraries and .NET framework classes, web development with ASP.NET, Silverlight and web services, plus topics like WPF, testing, metaprogramming, system administration, embedding IronPython in .NET applications and so on. The foreword is by Jim Hugunin and Dino Viehland is the technical editor. Many thanks to all those who helped, including those who gave feedback during the early access program. All the best, Michael Foord -- 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] py to ip
I don't know much about remote COM (is that the same as DCOM?). IronPython supports invocation on OLEAUT objects. It has only minimal support for creating such objects (via. clr.AddReferenceToTypeLib), and otherwise relies on the user to create the object using the CLR (Type.GetTypeFromProgID) or other means. You can check if any of the Activator.CreateInstance overloads (http://msdn.microsoft.com/en-us/library/system.activator.createinstance.aspx) support remote COM. Furthermore, I doubt if Mono supports even local COM interop. If you can't do it from C# on Mono, you won't be able to do it from IronPython on Mono either. I think you will need to find COM adapters that allow you to access COM from Linux and use those... -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Glauco Uri Sent: Wednesday, February 04, 2009 12:49 AM To: Discussion of IronPython Subject: Re: [IronPython] py to ip Shri Borde ha scritto: See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx for the details. Thank you Shri, i've done some try and this still work well: IronPython 2.0 (2.0.0.0) on .NET 2.0.50727.1433 Type help, copyright, credits or license for more information. import System System.Type.GetTypeFromProgID(DS.Channel) System.RuntimeType object at 0x002B [System.__ComObject] qq = System.Type.GetTypeFromProgID(DSA.Channel) System.Activator.CreateInstance( qq ) System.__ComObject (_Channel) object at 0x002C But now i've some question: - the GetTypeFromProgID method let me use an installed COM objec over the PC still running this ipy script. This don't use Interop i think If this is corerct i cannot in any way use remotley this object? Try to explain my issue: I'm writing a web application over a linux Server (A). Some financial data come from Thomson Datastream using this COM obj installed on a Windows Server (B). My purpose is to call this COM remotely from linux server. probably i'm doing somethin wrong but from ipy description i've understood this i possible. Thank's Glauco ___ 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] py to ip
See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx for the details. import System t = System.Type.GetTypeFromProgID(Excel.Application) excel = System.Activator.CreateInstance(t) wb = excel.Workbooks.Add() -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of António Piteira Sent: Tuesday, February 03, 2009 9:15 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] py to ip I'm sorry, forget what I said... I have done AddReferenceToFile, my mistake. But still, what is the output? - How is the best practice to convert this code in Iron? import win32com.client win32com.client.Dispatch(DS.Channel) win32com.gen_py.DSA -_Channel instance at 0x15331416 I've tryed this but don't work: import clr clr.AddReferenceToFile(DS.dll) import DS clr.SetCommandDispatcher( DSX.Channel ) dll was converted following the instruction in Tutorial.htm Thank you Glauco ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] Welcome David DiCato
Please welcome David DiCato to the IronPython team. He has his first shelveset in the Snap queue (queue.__init__ calls clear) already. You should hopefully hear more from him in the mailing list. Here is his intro in his own words. Hi everyone, I'm David DiCato, the new Dev on the IronPython team. I grew up in Surf City (i.e. Huntington Beach, CA) and moved just 50 miles north to go to school in Pasadena. At Caltech, I earned my BS in Computer Science, applied to Microsoft after a short break, and the rest is history. Although I have never touched a surf board, I like to dabble in snowboarding, as well as piano, guitar and biking, although I'm good at none of these things. I'm also a big fan of music, incl. classic rock, punk and electronic, and film, incl. Kubrick, Hitchcock and Scorsese. Thanks, Shri ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Return value for ADODB .Execute() call?
Using clr.Reference[int] should work if ra is an in-out (VT_BYREF) parameter. Note that not many OleAut APIs use VT_BYREF. Jscript does not support in-out parameters and the API would not be usable form Jscript. We do have the option of returning a tuple with the recordset and the number of records, just like pywin32, by checking the ITypeInfo if any of the parameters are VT_BYREF. We even had this working at some point. However, we have decided not to use ITypeInfo to check the type of parameters in order to keep the code paths the same when there is no typelib available. If you run into lots of APIs with in-out parameters, do let us know. Its something we could revisit for IPy 2.1. I will collect a list of such APIs in the Known Issues section in my blog at http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx for tracking purposes. Using clr.Reference will always work now and in the future, with or without typelibs being available. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Wednesday, August 27, 2008 1:10 PM To: Discussion of IronPython Subject: Re: [IronPython] Return value for ADODB .Execute() call? On Wed, Aug 27, 2008 at 12:17 PM, Vernon Cole [EMAIL PROTECTED] wrote: We can't pass the ra parameter in python, so pywin32 returns a tuple with the recordset and the number of records. How do I retrieve the number of records (for a non-row-returning query) in Iron? Presumably, Execute expects you to pass a VT_I4 | VT_BYREF so that it can store the value in the reference. If this were for a CLR API, you'd pass an int reference by using a variable of type clr.Reference[int](). I don't know that this will work for COM, but I assume that it would: ra = clr.Reference[int]() self.cmd.Execute(ra) recordCount = ra.Value -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] How do I determine whether a database supports transactions?
IPy does intend to support COM well. See http://blogs.msdn.com/shrib/archive/2008/07/30/idispatch-support-on-in-ironpython-beta-4.aspx. If something does not work, please do report a bug. The following worked for me. So using the natural indexing syntax is what you need. c:\vsl\Merlin\Mainipyd import System t = System.Type.GetTypeFromProgID(ADODB.Connection) com = System.Activator.CreateInstance(t) com.Properties[com.Properties.Count - 1] System.__ComObject (Property) object at 0x002F com.Properties[com.Properties.Count] Traceback (most recent call last): File stdin, line 1, in module EnvironmentError: Item cannot be found in the collection corresponding to the requested name or ordinal. Thanks, Shri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Thursday, August 21, 2008 5:57 AM To: Discussion of IronPython Subject: Re: [IronPython] How do I determine whether a database supports transactions? On Wed, Aug 20, 2008 at 10:55 PM, Seo Sanghyeon [EMAIL PROTECTED] wrote: 2008/8/21 Curt Hagenlocher [EMAIL PROTECTED]: In the long term, I think you're definitely better off rewriting against ADO.NET, but I can certainly see the attraction in getting something to work more quickly if you can continue to use the COM ADO objects. Especially, when it seems to me that interface provided by CPython/win32com is almost compatible with IronPython/.NET COM interop. Definitely. No doubt I'm just bitter as a result of bad experiences with classic ADO at my previous job. :) -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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] [OT] x64 vs x86 (was: RE: Informal Poll: measuring IronPython performance under x64 OSes)
For throughput performance, the Just-in-time compilers used by the CLR on x86 and x64 are different code bases, and so have different perf characteristics So in this case, yes, the x64 compiler is not as mature for this environment (JIT compilation). It something that can change going forward. I do not what the specific plans are for improving the x64 JIT... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Trent Nelson Sent: Wednesday, August 20, 2008 3:56 PM To: Discussion of IronPython Subject: [IronPython] [OT] x64 vs x86 (was: RE: Informal Poll: measuring IronPython performance under x64 OSes) Slightly off-topic: I'm fascinated by x64 vs. x86 performance comparisons like these, especially when x64 lags (often significantly) behind x86. What's going on here? Does the sheer size difference between x64 code and x86 code trump all other benefits offered by x64? What about all the extra registers available? (Or is that a non-issue given the prolific register re-naming an Intel x86 chip does these days?) Is it just that compilers generating x64 code just aren't as mature as x86 compilers yet? Or do we incur a penalty from WoW64? Can we never expect the performance of x64 code to surpass x86 code? Surely the momentum towards x64 (try buy a non-x64 CPU these days) is sustained by something other than having access an addressable memory area greater than 2^32? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Fugate Sent: 20 August 2008 22:40 To: Discussion of IronPython Subject: Re: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes From what I've seen on the mailing list and several emails sent directly to me there seems to be about a 50-50 split between x86/x64 interest. Anyone interested in x86 vs x64 IronPython performance might want to check out the following data points taken from two identical Vista machines that differ only in terms of OS bitted-ness: * MAY 2008 - IronPython startup performance is 25% slower on x64 than x86. * JUNE 2007 - IronPython startup performance was %32 slower on x64 than x86. * MAY 2008 - PyBench (Calls) is around 33% slower on x64 than x86. * JUNE 2007 - PyBench (Calls) was 34% slower on x64 than x86. * MAY 2008 - PyStone is 40% slower on x64 than x86. * JUNE 2007 - PyStone is %36 slower on x64 than x86. As you can see, although IronPython performance in given areas may change over the course of a year (PyBench Calls was about 10% faster in May 2008), the delta between IronPython on x86 and x64 platforms pretty much stays the same for a given benchmark. The principal reason behind this is IronPython has few (any?) x64 only code paths. Any differences in performance should be due to differences between the x86 and x64 CLRs. My disclaimer on this statement is that deltas can vary widely depending upon which benchmark we look at (e.g., the delta for PyBench Lists between x86/x64 is under 10%). From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Fugate Sent: Monday, August 18, 2008 2:43 PM To: Discussion of IronPython Subject: [IronPython] Informal Poll: measuring IronPython performance under x64 OSes Hi everyone, one of the things the IronPython test team does daily is run a set of standardized benchmarks against the latest internal build of IronPython. We're in the process of reevaluating the platforms we measure these benchmarks on with the end goal of increasing the number of tests we can run. For example, if we could cut x64 Vista from the list of platforms, the x64 Vista machine(s) could be reimaged to run new benchmarks we wouldn't have had the resources for before. Alternatively, we might reimage the x64 Vista machine(s) as some other platform we don't currently test under. Of course in such a scenario we'd still run other classifications of tests under x64 Vista. I wanted to hear peoples' opinions on the importance of measuring IronPython performance under x64 Windows OSes before we make any decisions on this. First off, how many people out there are actually running IronPython under a 64-bit OS? Would it be sufficient for us to report news on IronPython performance in terms of 32-bit platforms? Thanks, The IronPython Team ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Patched, profiling IronPython executable?
Have you tried using the VS profiler on a precompiled dll? I don't know how well it works, but VS profiler needs IL on disk, and with precompilation, you have that. There is still IL generated on the fly for rules, but you might be able to get some reasonable numbers. Thanks, Shri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Orestis Markou Sent: Friday, August 15, 2008 9:52 AM To: Discussion of IronPython Subject: Re: [IronPython] Patched, profiling IronPython executable? Thanks, I'll have a look at that. Hopefully it will help the effort of porting Resolver One to IP2. Dino Viehland wrote: FastCallable's certainly the right spot if anything will come close. My main concern is that it'll probably leave a lot of stuff out... In 2.0 this is actually easier. You could modify the DLR in MetaAction.cs to wrap every single dynamic operation - whether that be addition, calling something, getting a member, etc... There's a method called GetMetaObjectRule and it has: Expression body = rewriter.VisitNode(AddReturn(binding.Expression, retType)); You could modify this to be something like: Expression tmp = Expression.Variable(body.Type); body = Expression.Scope( Expression.Call( Expression.Comma( Expression.Call(typeof(MyType).GetMethod(Enter)), // MyType is some public type somewhere... Expression.Assign(tmp, body), Expression.Call(typeof(MyType).GetMethod(Exit)), tmp ) ), tmp ) ); And you'd get information on every call - warning, this code was compiled with Outlook. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Orestis Markou Sent: Friday, August 15, 2008 2:25 AM To: users@lists.ironpython.com Subject: [IronPython] Patched, profiling IronPython executable? Hi, following all the discussion about profiling etc, I was poking around in IP1.1.2 source code, trying to find out if there is a 'bottleneck' of sorts, that all function calls are threaded through. My thinking was that it would be then possible to surround this with profiling information, logging time taken etc. and compile a profiling ipy.exe. From my venture, I think that ICallable is what I should be looking for. I see that it has many implementors, but I guess FastCallable (in all its generated glory) should capture a lot of the cases, right? Am I even on the right track here? Orestis Markou ___ 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 ___ 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] Horrible performance regression of exec on IP2
Done Thanks, Shri -Original Message- From: Dino Viehland Sent: Monday, August 11, 2008 1:54 PM To: Shri Borde Subject: RE: [IronPython] Horrible performance regression of exec on IP2 Sounds like a good plan - do you want to add those comments to the bug? :) -Original Message- From: Shri Borde Sent: Monday, August 11, 2008 1:53 PM To: Dino Viehland Subject: RE: [IronPython] Horrible performance regression of exec on IP2 I believe that when Jacob enabled interpretation for exec, we used to compile code for exec if it had loops in it. That code no longer seems to be around, and now we will interpret the same. We could put back that heuristic. It would not help with Seo's example as it has a recursive function definition, but we can add class and function definitions to the list of heuristics as well. We could restrict interpretation to straight line code consisting of statements - which would still satisfy the main scenario of good per fro exec/evaling of simple code snippets. Thanks, Shri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Monday, August 11, 2008 1:29 PM To: Discussion of IronPython Subject: Re: [IronPython] Horrible performance regression of exec on IP2 This is probably because we'll interpret code that is executed using exec. So anything very computationally heavy will be slow in exec. Maybe we need a way to disable that. If you want to see what it'd be like if we weren't interpreting you could use compile() first. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seo Sanghyeon Sent: Monday, August 11, 2008 1:20 PM To: users@lists.ironpython.com Subject: [IronPython] Horrible performance regression of exec on IP2 This is just to let you know that I filed a CodePlex issue on this topic. Please comment (and vote!) there. http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17781 In particular, I am interested in the result of execfib.py on .NET. Current data is on Mono. -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com Sample disclaimer text ___ 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] CLS compilation
I am changing the subject to better reflect the discussion. I have posted a
blog at
http://blogs.msdn.com/shrib/archive/2008/07/24/cls-compilation-of-ironpython.aspx
discussing some issues I see.
Keith, as far as exposing IronPython types as System.Type, its not just a
question of inheriting from System.Type. If we did just that, the resulting
Type would not be usable from important APIs like Activator.CreateInstance,
from IL instructions like newobj, etc. because the CLR has special knowledge
about the System.Type object it creates from metadata.
Also, LINQ to SQL does look like an interesting scenario. I mention this at the
end of the blog. However, the reason to collect real use cases is to know
exactly what features are needed. Supporting the full range of CLS features may
not be necessary. Knowing how folks are wanting to use the feature can guide
the design of the feature in the future. For example LINQ to SQL only needs
CustomAttributes on types but not on methods AFAIK. This may could make a
significant difference as support CustomAttributes on method is much more
complicated.
So do send in other use cases you have run into...
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Wednesday, July 23, 2008 7:41 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython Post 2.0 Roadmap
The only problem w/ the existing Type and MemberInfo classes is that they all
require inheritance demands to inherit from them. That prevents us from
subclassing them in anything core because it won't work in Silverlight or other
partial trust scenarios. But it is something we've been working w/ the CLR
team on getting fixed so we'll be able to take that approach in the future -
there's other areas where it'd be useful as well.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith J. Farmer
Sent: Wednesday, July 23, 2008 7:30 PM
To: Discussion of IronPython; Discussion of IronPython
Subject: Re: [IronPython] IronPython Post 2.0 Roadmap
I can answer both in one: To be able to use IronPython to create data classes,
marked up with attributes, to be consumed by APIs probably written in something
other than IronPython.
That's it.. quite simple.
Example of such an API: LINQ to SQL. Or LINQ to whatever, since outside of of
Objects and XML, things pretty much end up with mapping metadata and attributes
are one of the first places to look for that.
And so, in light of the DLR effort, and the general push to make the static
languages be able to work well with the dynamics, I think it's only right that
the DLR languages be able to expose their dynamic types in such as way as to be
transparent to the static languages. That's why I pointed out that Type is an
abstract class and the MemberInfo subclasses themselves appear to be
subclassable. It really appears that the API is there, waiting to be
implemented.
Otherwise, really, the dynamic languages are completely unusable for certain
APIs -- they just don't interact with the reflection API in such a way that
libraries can consume in a reasonable, language-neutral manner.
From: [EMAIL PROTECTED] on behalf of Curt Hagenlocher
Sent: Wed 7/23/2008 4:39 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython Post 2.0 Roadmap
So, we had a brief hallway discussion today about this topic, and the upshot is
that I'm interested in hearing your real world use cases for
a) attributes, and
b) static type generation in general
By use case, I mean a scenario that's specifically relevant to you today. By
relevant, I mean that it would be *nice* to be able to write a PowerShell
extension in Python, but if you didn't end up writing the extension in another
language, then it doesn't really count for what I'm looking for. :)
On Mon, Jul 21, 2008 at 4:16 PM, Keith J. Farmer [EMAIL
PROTECTED]mailto:[EMAIL PROTECTED] wrote:
We are talking about *new* features, but you're limiting yourself to existing
APIs?
If, for the sake of working nicely with the DLR, the existing reflection API
needs to be modified to deal with a more dynamic world, that's not outside the
realm of possibility in my books. After all, there has always been talk of IP
being able to expose static types for consumption outside of IP. I don't see
that this is any less possible now than it was at the start.
Incidentally, Type is an abstract class. Also, ParameterInfo isn't sealed, and
implements ICustomerAttributeProvider, which is a public interface:
public interface ICustomAttributeProvider
http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:2.0.0.0:b77a5c561934e089/System.Reflection.ICustomAttributeProvider
{
// Methods
object
http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:2.0.0.0:b77a5c561934e089/System.Object
[] GetCustomAttributes
Re: [IronPython] The slow part of IronPython
Dan, you could try turning on interpretation for all of your scripts. It might
hurt your throughput (depending on how compute-intensive your script is), but
it would be an interesting exercise to see how much it helps startup. The way
to do this on the desktop is to use ipy.exe -X:Interpret.
Since you are looking at Silverlight, the steps are more complicated. Here are
the steps.
Include a C# dll with the following code:
using System;
using Microsoft.Scripting.Runtime;
namespace ScriptingHelpers {
public class ScriptingHelper {
public static LanguageContext GetCurrentLanguageContext(CodeContext
context) {
return context.LanguageContext;
}
}
From your startup Python script, do the following:
# This should be the very first Python file that is executed
import clr
clr.AddReference(ScriptingHelpers.dll)
from ScriptingHelpers import ScriptingHelper
# The DLR will automatically pass in a CodeContext to the function call
currentContext = ScriptingHelper.GetCurrentLanguageContext()
currentContext.Options.InterpretedMode = True
# Now import the rest of the Python scripts.
# These should hopefully load faster since they will be interpreted
import someLargeModule1
import someLargeModule2
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Eloff
Sent: Wednesday, June 25, 2008 9:11 AM
To: Discussion of IronPython
Subject: Re: [IronPython] The slow part of IronPython
What if I used background threads to import some packages at program
start? I imagine there is a race condition here if the background
thread is still importing module x and the main thread starts to do
the same, but if the worst case is it's parsed/compiled twice, but
imported once, it doesn't matter. The work the background thread does
is free on a multi-core machine.
I may also be able to tweak my code to import some modules at runtime
if they aren't used in the initial startup code path.
IronPython is slow to startup, but really, as Foord pointed out, it's
not noticeable once you start importing.
On Tue, Jun 24, 2008 at 8:22 PM, Dino Viehland
[EMAIL PROTECTED] wrote:
Well IsolatedStorage probably isn't good enough. The problem is we actually
save a real .NET assembly to disk and do so using reflection - which is the
only way this offers any benefits - the slow part is generally compilation.
So Reflection.Emit would have to support IsolatedStorage for this to work.
If you really wanted to use it out of Silverlight you could probably save it
to disk on the desktop CLR, ildasm it, edit it, update the references to the
Silverlight assemblies, and then ilasm it (or programmatically w/ something
like Cecil I suppose). But we'd never actually support that or advise you do
it :)
You'll also want to measure the benefit you get w/ your code before you even
try - the speed improvement of pre-compilation can be less significant than
you'd really like. The best improvements come when you can compile multiple
modules into a single file. But compiling one module per file ends up not
being much of a gain. It's also not free - it has the same performance cost
as the lightweight scopes I mentioned before. And there's still a lot of
code gen for user-defined types and call sites.
The good news, I suppose, is startup is now our own biggest performance
concern - working set's at the top of the list as well. Throughput is
largely higher across the board in 2.0 except for in some crazy dynamic
scenarios. So it's definitely where our performance work will focus on in
the future and we also have a few more ideas to consider as well. Likely
it'll be a combination of many things that ultimately speeds this up. Sorry
it won't get immediately better - I'm as unhappy about it as you :(.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Eloff
Sent: Tuesday, June 24, 2008 5:58 PM
To: Discussion of IronPython
Subject: Re: [IronPython] The slow part of IronPython
There's a couple of plans a foot. We have been working on a pre-compilation
feature like .pyc for IronPython 2.0 It's actually in Beta 3 but
unfortunately it doesn't quite work yet which is the reason we haven't said
anything. It will be there (and working!) in beta 4.
Wow, looking forward to that!
that's the short term solution but unfortunately it won't really work with
Silverlight - there's no way to compile against the Silverlight mscorlib from
the desktop CLR and Silverlight doesn't support saving assemblies to disk.
That seems more like a Silverlight problem than an IronPython one.
However, I can in Silverlight save arbitrary data to IsolatedStorage
(client side). This would, I think, enable caching the compiled
modules and loading them again on a per user basis, if only I have the
right api in IronPython to get the compiled module
Re: [IronPython] Viewlets: Any F# experts here?
Michael, what is the CLR stack trace (-X:ShowClrExceptions)?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jimmy Schementi
Sent: Thursday, June 26, 2008 3:04 PM
To: Discussion of IronPython
Cc: Luke Hoban
Subject: Re: [IronPython] Viewlets: Any F# experts here?
Adding Luke Hoban, the F# ninja at Microsoft =)
Luke, any ideas? Swing by my office if you are confused.
-Original Message-
From: [EMAIL PROTECTED] [mailto:users-
[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Thursday, June 26, 2008 2:59 PM
To: Discussion of IronPython
Subject: [IronPython] Viewlets: Any F# experts here?
The viewlets that come with VSLab look *really* cool. They're based on
F# so I decided to see if they could be used from IronPython.
http://www.codeplex.com/vslab
The dependencies are pretty hefty. You need F# installed *and* Managed
DirectX (June 2008 SDK ~450mb seems to fulfil the dependency).
To get at the viewlet assemblies you need Visual Studio Pro installed
as
well, but they can be extracted from the VSLabs msi installer without
VS
Pro.
Ok, so with all the dependencies installed I attempt to use them - and
*boom*. Anyone here got any ideas?
IronPython 2.0 Beta (2.0.0.3000) on .NET 2.0.50727.1434
Copyright (c) Microsoft Corporation. All rights reserved.
import clr
clr.AddReference('vslabfsicore')
clr.AddReference('vslabviewlets')
clr.AddReference('vslabcore')
from GraphViewlet import GraphControl
g = GraphControl()
Traceback (most recent call last):
File stdin, line 1, in module
File vslabviewlets, line unknown, in .ctor
File vslabfsicore, line unknown, in .ctor
File System.Windows.Forms, line unknown, in get_Controls
File System.Windows.Forms, line unknown, in get_Properties
SystemError: Object reference not set to an instance of an object.
Interesting that the explosion is inside winforms. Referencing that
assembly first makes knows difference.
Michael Foord
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/
___
Users mailing list
Users@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
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Viewlets: Any F# experts here?
Actually, -X:ExceptionDetail is the more important option. Could you try that?
It will you the System.Exception stack trace.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Thursday, June 26, 2008 3:39 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Viewlets: Any F# experts here?
Shri Borde wrote:
Michael, what is the CLR stack trace (-X:ShowClrExceptions)?
Not much more useful I'm afraid.
C:\compile\VSLabC:\compile\IronPython-2.0B3\ipy.exe
-X:ShowClrExceptions viewle
t.py
Traceback (most recent call last):
File viewlet.py, line 4, in viewlet.py
File vslabviewlets, line unknown, in .ctor
File vslabfsicore, line unknown, in .ctor
File System.Windows.Forms, line unknown, in get_Controls
File System.Windows.Forms, line unknown, in get_Properties
SystemError: Object reference not set to an instance of an object.
CLR Exception:
NullReferenceException
:
Object reference not set to an instance of an object.
Michael
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jimmy Schementi
Sent: Thursday, June 26, 2008 3:04 PM
To: Discussion of IronPython
Cc: Luke Hoban
Subject: Re: [IronPython] Viewlets: Any F# experts here?
Adding Luke Hoban, the F# ninja at Microsoft =)
Luke, any ideas? Swing by my office if you are confused.
-Original Message-
From: [EMAIL PROTECTED] [mailto:users-
[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Thursday, June 26, 2008 2:59 PM
To: Discussion of IronPython
Subject: [IronPython] Viewlets: Any F# experts here?
The viewlets that come with VSLab look *really* cool. They're based on
F# so I decided to see if they could be used from IronPython.
http://www.codeplex.com/vslab
The dependencies are pretty hefty. You need F# installed *and* Managed
DirectX (June 2008 SDK ~450mb seems to fulfil the dependency).
To get at the viewlet assemblies you need Visual Studio Pro installed
as
well, but they can be extracted from the VSLabs msi installer without
VS
Pro.
Ok, so with all the dependencies installed I attempt to use them - and
*boom*. Anyone here got any ideas?
IronPython 2.0 Beta (2.0.0.3000) on .NET 2.0.50727.1434
Copyright (c) Microsoft Corporation. All rights reserved.
import clr
clr.AddReference('vslabfsicore')
clr.AddReference('vslabviewlets')
clr.AddReference('vslabcore')
from GraphViewlet import GraphControl
g = GraphControl()
Traceback (most recent call last):
File stdin, line 1, in module
File vslabviewlets, line unknown, in .ctor
File vslabfsicore, line unknown, in .ctor
File System.Windows.Forms, line unknown, in get_Controls
File System.Windows.Forms, line unknown, in get_Properties
SystemError: Object reference not set to an instance of an object.
Interesting that the explosion is inside winforms. Referencing that
assembly first makes knows difference.
Michael Foord
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/
___
Users mailing list
Users@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
___
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/
http://www.trypython.org/
http://www.ironpython.info/
http://www.theotherdelia.co.uk/
http://www.resolverhacks.net/
___
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] DLR documentation
Take a look at
http://blogs.msdn.com/ironpython/archive/2008/03/16/dlr-resources.aspx as well
for a list of useful links.
Thanks,
Shri
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher
Sent: Tuesday, June 24, 2008 7:31 AM
To: Discussion of IronPython
Subject: Re: [IronPython] DLR documentation
The DLR is pretty sparsely documented today. Some of the available resources
are the hosting spec:
http://compilerlab.members.winisp.net/dlr-spec-hosting.pdf
And some blogs that talk about implementing languages on the DLR:
http://blogs.msdn.com/mmaly/
http://www.dotnetguru.org/us/dlrus/DLR2.htm
On Mon, Jun 23, 2008 at 12:50 PM, Artur Krosny [EMAIL PROTECTED] wrote:
Hi,
Is there any DLR documentation available somewhere ?
I am playing with ToyScript to learn it and I like
to know if it would be possible to implement scope
declarations for functions. Something like :
static def test() {..}
Artur
___
Users mailing list
Users@lists.ironpython.commailto: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] Welcome Curt to the IronPython team
That was subtle indeed. So to fix that, I am pleased to welcome Curt to the IronPython team. Curt has been active in both the IronPython and IronRuby mailing lists, and we are excited to have him officially be working on these projects. Curt already has a fix in socket support which he should be checking in shortly. This might be the second-fastest checkin for a new dev. Dino had checked in as part of his interview even before he joined the team, but I can't really hold this against Curt since we couldn't accept his patches before :) Curt will be spending sometime initially on IronRuby too. Thanks, Shri Want to work on IronPython, IronRuby, F#? Visit http://blogs.msdn.com/ironpython -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Wednesday, May 07, 2008 1:06 AM To: Discussion of IronPython Subject: Re: [IronPython] socket support in 1.1.2 Curt Hagenlocher wrote: Well, Dino tells me that they can't accept any contributions from outside Microsoft. So in order to best serve the IronPython community, I've taken the arguably extreme step of joining the IronPython team as a developer just to be able to commit this change. Afterwards, I expect to stick around for a while and work on Visual Studio integration. That's a subtle announcement Curt. Congratulations to you and the ongoing success of IronPython! :-D (I'm interested in the progress of Coils as well - and have an interesting idea for it, but I need to finish my book first...) Michael Foord I still expect to be working on my wrapper project after hours -- I've been quiet about it recently largely because I got sidetracked by an attempt to add p/invoke support. Expect something new in the next week or so. On Fri, Apr 25, 2008 at 9:43 AM, Michael Foord [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Curt Hagenlocher wrote: I've attached a patch against 1.1.1 that (I think) fixes this. It works for my test case, anyway. We currently ship Microsoft binaries rather than compiling from source - so we'd rather wait for 1.1.2 than patch at this stage... but thanks. Michael ___ 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 ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] COM Late Binding in IronPython
I am not sure what the exact question is. However, I have posted the following at http://blogs.msdn.com/shrib/archive/2008/04/10/ole-automation-idispatch-support-in-ironpython.aspx to help understand what -X:PreferComDispatch does. OLE automation (IDispatch) support in IronPython IronPython 1.X supported COM interop by building on top of the COM interophttp://msdn2.microsoft.com/en-us/library/6bw51z5z(VS.80).aspx support built into the CLR. This relies on the use of interop assemblies for managed code to access COM objects. The interop assembly can be accessed in different ways: 1. clr.AddReference(interopAssembly) - This is the preferred mechanism so that the interop assembly does not have to be created multiple times. The down-side is that it complicates deployment. You have to ensurehttp://msdn2.microsoft.com/en-us/library/697w37zd(VS.80).aspx that the interop assembly exists on the machine. 2. Having IronPython automatically generate it on the fly - if you have a OLE automation object, IronPython tries to find its type library (TLB) and then to convert the TLB to an interop assembly on the fly using the TypeLibConverterhttp://msdn2.microsoft.com/en-us/library/system.runtime.interopservices.typelibconverter(VS.80).aspx class. The advantage is that this works seamlessly as long as there is a type library on the machine. The down-side is that this conversion can take a long time for large TLB files. This is how Word could be accessed. It requires the interop assembly Microsoft.Office.Interop.Word.dll to be available on the machine. c:\ipy.exe IronPython 2.0 Beta (2.0.0.1000) on .NET 2.0.50727.1433 Copyright (c) Microsoft Corporation. All rights reserved. import clr clr.AddReference(Microsoft.Office.Interop.Word) from Microsoft.Office.Interop.Word import ApplicationClass word = ApplicationClass() word.Visible = True doc = word.Documents.Add() doc.Range().Text = Hello from IronPython word.Quit() IronPython 2.0 has added support for interacting with OLE automation objects using the IDispatch interface. This completely eliminates the need for interop assemblies. This is the same mechanism that VBAhttp://msdn2.microsoft.com/en-us/isv/bb190538.aspx late-bound code and also WSHhttp://msdn2.microsoft.com/en-us/library/9bbdkx3k.aspx use to interact with OLE automation object. This feature can currently be accessed using the -X:PreferComDispatch command line option. Here is an interactive session showing access to Word. There are no interop assemblies in the picture. c:\ipyd -X:PreferComDispatch IronPython 2.0 Beta (2.0.0.1000) on .NET 2.0.50727.1433 Copyright (c) Microsoft Corporation. All rights reserved. import clr import System wordTypeLibGuid = System.Guid(00020905---C000-0046) clr.AddReferenceToTypeLibrary(wordTypeLibGuid) from Word import Application word = Application() word.Visible = True doc = word.Documents.Add() doc.Range().Text = Hello from IronPython word.Quit() The feature is not complete yet, and so is not currently (April 08) enabled by default. I cant say for sure when we will enable it by default, but its already quite stable for many real-world uses. We run all of our COM tests in both modes - using interop assemblies and using IDispatch. There are a few differences between the two cases in the minute details, but the mainline scenarios work well in both. This feature is implemented in the DLR, and so should be accessible from all DLR-based languages with little effort. Thanks, Shri Want to work on IronPython, IronRuby, F#?http://blogs.msdn.com/ironpython/archive/2008/02/25/ironpython-ironruby-and-f-openings-in-dev-test-and-pm.aspx Visit http://blogs.msdn.com/ironpython From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davy Mitchell Sent: Wednesday, April 09, 2008 1:31 PM To: Discussion of IronPython Subject: [IronPython] Late Binding in IronPython Hi List, It seems odd posting here with my work hat on but here goes... :-) !! I've been looking at using IronPython and COM to work with some COM objects with VB6 (Project Compatibility - a *TOTAL* nightmare for interop). In VB.net we get round this with CreateObject which works well though somewhat limit. Is -X:PreferComDispatch flag intended to be an equivalent for IronPython and any other DLR languages? VBX? Thanks, Davy Mitchell -- Davy Mitchell Blog - http://www.latedecember.co.uk/sites/personal/davy/ Twitter - http://twitter.com/daftspaniel Skype - daftspaniel http://needgod.com inline: image001.gifinline: image002.gif___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] UI Automation and ControlTypeProperty
If you can check if the failing API calls Assembly.GetCallingAssembly by placing a breakpoint in the debugger, that would be 99% confirmation that it is the same issue. Alternatively, you could change the C# code to use Reflection.Emit to create a method which invokes the UI Automation API. If this fails, it is the same bug. The bug affects all dynamic code (IronPython source code gets compiled to Reflection.Emit on the fly). I have pinged the UI Automation team to find out the status of the bug. You could open a bug in the IronPython tracker. Given that its most likely not an IronPython issue, we may not be able to get to it in time to unblock you. Thanks, Shri Want to work on IronPython, IronRuby, F#? Visit http://blogs.msdn.com/ironpython -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcel Sent: Monday, March 24, 2008 1:06 PM To: users@lists.ironpython.com Subject: Re: [IronPython] UI Automation and ControlTypeProperty On Mar 24, 7:14 am, Shri Borde [EMAIL PROTECTED] wrote: UI Automation did have a problem with IronPython. Seehttp://blogs.msdn.com/shrib/archive/2008/03/24/ironpython-cannot-call I am not sure if the issue has been fixed yet by the UI Automation team. Or if you are running into that same issue or something else. So the problem is with the UI Automation? Is there a way to verify this comes from the same root cause? Should I submit the issue in the codeplex issue tracker? TIA, -- Marcel ___ 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] DLR resources
I have started compiling a list of DLR resources in this blog - http://blogs.msdn.com/ironpython/archive/2008/03/16/dlr-resources.aspx. I will try and keep it updated so that folks have one place to start when hunting for DLR information. If you have other links that I should add, send them my way... Thanks, Shri Want to work on IronPython, IronRuby, F#?http://blogs.msdn.com/ironpython/archive/2008/02/25/ironpython-ironruby-and-f-openings-in-dev-test-and-pm.aspx Visit http://blogs.msdn.com/ironpython ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] AttributeError: '__ComObject' object has no attribute 'Visible' with -X:PreferComDispatch
Hi,
Could you include the following information please:
1. Is this with the modified registry or without?
2. Can you show the complete output with -X:ExceptionDetail?
3. If you do dir(e) before doing e.Visible = True, does that change the
behavior?
4. What happens if you do *not* use -X:PreferComDispatch? You will have to use
the following script.
c:\Testipy.exe -X:TabCompletion -X:ExceptionDetail
IronPython console: 2.0
Copyright (c) Microsoft Corporation. All rights reserved. import clr
clr.AddReference(Microsoft.Office.Interop.Excel) # expects the PIA to be
in the GAC on in the current folder
from Microsoft.Office.Interop.Excel import *
e = ApplicationClass()
ApplicationClass.Visible.SetValue(e, True)
Thanks,
Shri
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nekomaho
Sent: Saturday, December 22, 2007 12:18 AM
To: Discussion of IronPython
Subject: Re: [IronPython] AttributeError: '__ComObject' object has no attribute
'Visible' with -X:PreferComDispatch
Hi,
I get no AttributeError with IronPython 2.0 Alpha 7.
thanks
Misha said - I should add that having the registry keys alone would only
help if Excel PIAs are in the GAC as well (when installing Excel - you would
choose .NET Interoperability support). You probably do not have the PIAs
installed.
The problem is just a matter of initialiazation order. The IDispatch support
was not initialized by the time the e.Visible = True statement was
executed. I have a fix and have just checked it in. The next IronPython drop
should have the fix. If you want a fix now, you can add the following lines
at the very start of PythonBinder.GetExtensionTypes.
// Ensure that the type is initialized. If
ReflectedTypeBuilder.RegisterAlternateBuilder was used,
// the alternate builder will get a chance to initialize the type.
DynamicHelpers.GetPythonTypeFromType(t);
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nekomaho
Sent: Friday, November 16, 2007 2:47 AM
To: Discussion of IronPython
Subject: Re: [IronPython] AttributeError: '__ComObject' object has no
attribute 'Visible' with -X:PreferComDispatch
Hi,
I changed registry but I get same error.
IronPython-2.0A6reg query
HKEY_CLASSES_ROOT\CLSID\{00024500---C000-0046}\InprocServer32
/s
! REG.EXE VERSION 3.0
HKEY_CLASSES_ROOT\CLSID\{00024500---C000-0046}\InprocServer32
Class REG_SZ Microsoft.Office.Interop.Excel.ApplicationClass
RuntimeVersion REG_SZ v1.1.4322
HKEY_CLASSES_ROOT\CLSID\{00024500---C000-0046}\InprocServer32\12.0.0.0
Class REG_SZ Microsoft.Office.Interop.Excel.ApplicationClass
RuntimeVersion REG_SZ v1.1.4322
IronPython-2.0A6ipy.exe -X:PreferComDispatch -X:TabCompletion
-X:ExceptionDetail
IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.832
Copyright (c) Microsoft Corporation. All rights reserved.
import clr
from System import Type, Activator
t = Type.GetTypeFromProgID('Excel.Application')
e = Activator.CreateInstance(t)
e.Visible = True
'__ComObject' object has no attribute 'Visible'
場所 Microsoft.Scripting.Ast.ThrowStatement.DoExecute(CodeContext context)
場所 Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
場所
Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeContext
callerContext, DynamicAction action, Object[] args, Object site, T target,
RuleSet`1 rules)
場所
Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeContext
context, T0 arg0, T1 arg1)
場所
Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7.Invoke2(DynamicSite`3
site, CodeContext context, T0 arg0, T1 arg1)
場所 Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context,
T0 arg0, T1 arg1)
場所 ##29(Object[] , CodeContext )
場所 Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean
tryEvaluate)
場所 Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
場所 Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
場所 Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code,
IScriptModule module)
場所 Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
場所 Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
場所 IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
場所 Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
AttributeError: '__ComObject' object has no attribute 'Visible'
Thanks
The behavior currently depends on whether or not the RCW gets strongly-typed
when it enters the managed world. As a workaround, the following registry
script Misha provided could fix your machine by registering the PIA:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{00024500---C000-0046}\InprocServer32]
[IronPython] Half the team OOF this week
Btw, half of our team is out this week for the Thanksgiving weekend. Dino is OOF starting Tuesday. So you may not get a prompt response this week. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Monday, November 19, 2007 4:16 PM To: Discussion of IronPython Subject: [IronPython] DLR Hosting Spec As I mentioned a couple of weeks ago we've been wrapping up work on designing the hosting APIs and just this past week we've started implementing the new hosting APIs. We'll be continuing this work off-and-on over the next few months so now is a great time to start collecting feedback on the design of the new APIs. One thing worth mentioning is the spec is incomplete, and the text that is there is not final. The conceptual introduction and the direction we're going is pretty solid. However, as we review the API reference sections in detail, as implementation feeds back on the design, and as we gather external feedback, we're updating the spec and code. The reason we're releasing this so early is to gather feedback on the design and functionality of the APIs. Any feedback you have would be appreciated. The new APIs will also start showing up incrementally in the next few releases of IronPython and the regular source drops of IronRuby. So soon you'll also be test out and experiment with the bits directly. This should give us plenty of time to take any feedback into consideration and update both the spec and code for the final DLR APIs. We look forward to any feedback you might have! You can grab the spec here: http://www.iunknown.com/files/dlr-spec-hosting.pdf If anyone would like a version in Word format we can send that so you can mark it up w/ track changes enabled :). ___ 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] AttributeError: '__ComObject' object has no attribute 'Visible' with -X:PreferComDispatch
Misha said - I should add that having the registry keys alone would only help
if Excel PIAs are in the GAC as well (when installing Excel - you would choose
.NET Interoperability support). You probably do not have the PIAs installed.
The problem is just a matter of initialiazation order. The IDispatch support
was not initialized by the time the e.Visible = True statement was executed.
I have a fix and have just checked it in. The next IronPython drop should have
the fix. If you want a fix now, you can add the following lines at the very
start of PythonBinder.GetExtensionTypes.
// Ensure that the type is initialized. If
ReflectedTypeBuilder.RegisterAlternateBuilder was used,
// the alternate builder will get a chance to initialize the type.
DynamicHelpers.GetPythonTypeFromType(t);
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nekomaho
Sent: Friday, November 16, 2007 2:47 AM
To: Discussion of IronPython
Subject: Re: [IronPython] AttributeError: '__ComObject' object has no attribute
'Visible' with -X:PreferComDispatch
Hi,
I changed registry but I get same error.
IronPython-2.0A6reg query
HKEY_CLASSES_ROOT\CLSID\{00024500---C000-0046}\InprocServer32 /s
! REG.EXE VERSION 3.0
HKEY_CLASSES_ROOT\CLSID\{00024500---C000-0046}\InprocServer32
Class REG_SZ Microsoft.Office.Interop.Excel.ApplicationClass
RuntimeVersion REG_SZ v1.1.4322
HKEY_CLASSES_ROOT\CLSID\{00024500---C000-0046}\InprocServer32\12.0.0.0
Class REG_SZ Microsoft.Office.Interop.Excel.ApplicationClass
RuntimeVersion REG_SZ v1.1.4322
IronPython-2.0A6ipy.exe -X:PreferComDispatch -X:TabCompletion
-X:ExceptionDetail
IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.832
Copyright (c) Microsoft Corporation. All rights reserved.
import clr
from System import Type, Activator
t = Type.GetTypeFromProgID('Excel.Application')
e = Activator.CreateInstance(t)
e.Visible = True
'__ComObject' object has no attribute 'Visible'
場所 Microsoft.Scripting.Ast.ThrowStatement.DoExecute(CodeContext context)
場所 Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
場所
Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeContext
callerContext, DynamicAction action, Object[] args, Object site, T target,
RuleSet`1 rules)
場所
Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeContext
context, T0 arg0, T1 arg1)
場所
Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7.Invoke2(DynamicSite`3
site, CodeContext context, T0 arg0, T1 arg1)
場所 Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0
arg0, T1 arg1)
場所 ##29(Object[] , CodeContext )
場所 Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean
tryEvaluate)
場所 Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
場所 Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
場所 Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code,
IScriptModule module)
場所 Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
場所 Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
場所 IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
場所 Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
AttributeError: '__ComObject' object has no attribute 'Visible'
Thanks
The behavior currently depends on whether or not the RCW gets strongly-typed
when it enters the managed world. As a workaround, the following registry
script Misha provided could fix your machine by registering the PIA:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{00024500---C000-0046}\InprocServer32]
Assembly=Microsoft.Office.Interop.Excel, Version=12.0.0.0,
Culture=neutral, PublicKeyToken=71E9BCE111E9429C
Class=Microsoft.Office.Interop.Excel.ApplicationClass
RuntimeVersion=v1.1.4322
[HKEY_CLASSES_ROOT\CLSID\{00024500---C000-0046}\InprocServer32\12.0.0.0]
Assembly=Microsoft.Office.Interop.Excel, Version=12.0.0.0,
Culture=neutral, PublicKeyToken=71E9BCE111E9429C
Class=Microsoft.Office.Interop.Excel.ApplicationClass
RuntimeVersion=v1.1.4322
Your script should work independent of whether the PIA is registered or not.
We will look into it and see what is going.
The implementation of -X:PreferComDispatch is still not complete. We are
working on improving it and will enable it by default once all issues are
flushed out. You are on the cutting edge and providing us with advance
feedback :)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nekomaho
Sent: Thursday, November 15, 2007 4:45 AM
To: Discussion of IronPython
Subject: Re: [IronPython] AttributeError: '__ComObject' object has no
attribute 'Visible'
Hi,
I use Windows XP Pro SP2 ja Office 2007 Pro ja.
IronPython-2.0A6ipy.exe
Re: [IronPython] AttributeError: '__ComObject' object has no attribute 'Visible' with -X:PreferComDispatch
The behavior currently depends on whether or not the RCW gets strongly-typed
when it enters the managed world. As a workaround, the following registry
script Misha provided could fix your machine by registering the PIA:
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\CLSID\{00024500---C000-0046}\InprocServer32]
Assembly=Microsoft.Office.Interop.Excel, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71E9BCE111E9429C
Class=Microsoft.Office.Interop.Excel.ApplicationClass
RuntimeVersion=v1.1.4322
[HKEY_CLASSES_ROOT\CLSID\{00024500---C000-0046}\InprocServer32\12.0.0.0]
Assembly=Microsoft.Office.Interop.Excel, Version=12.0.0.0, Culture=neutral,
PublicKeyToken=71E9BCE111E9429C
Class=Microsoft.Office.Interop.Excel.ApplicationClass
RuntimeVersion=v1.1.4322
Your script should work independent of whether the PIA is registered or not. We
will look into it and see what is going.
The implementation of -X:PreferComDispatch is still not complete. We are
working on improving it and will enable it by default once all issues are
flushed out. You are on the cutting edge and providing us with advance feedback
:)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of nekomaho
Sent: Thursday, November 15, 2007 4:45 AM
To: Discussion of IronPython
Subject: Re: [IronPython] AttributeError: '__ComObject' object has no attribute
'Visible'
Hi,
I use Windows XP Pro SP2 ja Office 2007 Pro ja.
IronPython-2.0A6ipy.exe -X:PreferComDispatch -X:TabCompletion
-X:ExceptionDetail
IronPython console: IronPython 2.0A6 (2.0.11102.00) on .NET 2.0.50727.832
Copyright (c) Microsoft Corporation. All rights reserved.
import clr
from System import Type, Activator
t = Type.GetTypeFromProgID('Excel.Application')
e = Activator.CreateInstance(t)
e.Visible = True
'__ComObject' object has no attribute 'Visible'
場所 Microsoft.Scripting.Ast.ThrowStatement.DoExecute(CodeContext context)
場所 Microsoft.Scripting.Ast.Statement.Execute(CodeContext context)
場所
Microsoft.Scripting.Actions.ActionBinder.UpdateSiteAndExecute[T](CodeContext
callerContext, DynamicAction action, Object[] args, Object site, T target,
RuleSet`1 rules)
場所
Microsoft.Scripting.Actions.DynamicSite`3.UpdateBindingAndInvoke(CodeContext
context, T0 arg0, T1 arg1)
場所
Microsoft.Scripting.Actions.DynamicSiteHelpers.UninitializedTargetHelper`7.Invoke2(DynamicSite`3
site, CodeContext context, T0 arg0, T1 arg1)
場所 Microsoft.Scripting.Actions.DynamicSite`3.Invoke(CodeContext context, T0
arg0, T1 arg1)
場所 ##29(Object[] , CodeContext )
場所 Microsoft.Scripting.ScriptCode.Run(CodeContext codeContext, Boolean
tryEvaluate)
場所 Microsoft.Scripting.ScriptCode.Run(ScriptModule module)
場所 Microsoft.Scripting.Hosting.CompiledCode.Evaluate(IScriptModule module)
場所 Microsoft.Scripting.Hosting.ScriptEngine.ExecuteCommand(String code,
IScriptModule module)
場所 Microsoft.Scripting.Shell.CommandLine.RunOneInteraction()
場所 Microsoft.Scripting.Shell.CommandLine.TryInteractiveAction()
場所 IronPython.Hosting.PythonCommandLine.TryInteractiveAction()
場所 Microsoft.Scripting.Shell.CommandLine.RunInteractiveLoop()
AttributeError: '__ComObject' object has no attribute 'Visible'
Thanks
This works for me as well. Could you please re-run your code snippet under
the -X:ExceptionDetail mode and send us the output? Also, what versions of
Windows and Office are being used?
Thanks
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mohammad
Tayseer
Sent: Wednesday, November 14, 2007 8:02 AM
To: Discussion of IronPython
Subject: Re: [IronPython] AttributeError: '__ComObject' object has no
attribute 'Visible'
It works for me. What version of Excel do you use??
Mohammad Tayseer
http://spellcoder.com/blogs/tayseer
- Original Message
From: nekomaho [EMAIL PROTECTED]
Hi,
I get AttributeError in IronPython 2.0A6 A5, but 2.0A4 is ok. why?
Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See
how.http://us.rd.yahoo.com/evt=51732/*http:/overview.mail.yahoo.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
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] i thought this is odd: using Interop on Microsoft Word
This could be fixed in IronPython but currently its expected.
docs[1] is calling into this indexer in Microsoft.Office.Interop.Word.dll. The
indexer method takes the index by-reference. Ie as object instead of just
object.
.method instance class Microsoft.Office.Interop.Word.Document
get_Item([in] object marshal( struct) Index)
{
} // end of method Documents::get_Item
IronPython thinks that is a ref parameter that could potentially by updated by
the call. Hence, it returns it back as one of the return values.
returnValues = docs[1]
returnValues[0] # real return value
Microsoft.Office.Interop.Word.DocumentClass
returnValues[1] # the by-ref param included in the return value.
1
In C#, you would have to use the ref keyword to index into docs. You can
simulate this in IronPython as such
docs[clr.Reference[object](1)]
Microsoft.Office.Interop.Word.DocumentClass
IronPython could fix this by paying attention to the [in] in the signature.
It appears as a custom attribute of type
System.Runtime.InteropServices.InAttribute on the parameter. I have opened
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=13641 to track
this.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelie
Sent: Friday, November 02, 2007 12:45 AM
To: IronPython Users
Subject: [IronPython] i thought this is odd: using Interop on Microsoft Word
Hello group,
import clr
clr.AddReference(Microsoft.Office.Interop.Word)
import Microsoft.Office.Interop.Word as Word
_progid_ = Word.Application
def get_active_object(progid):
from System.Runtime.InteropServices import Marshal
try:
app = Marshal.GetActiveObject(progid)
except:
app = None
return app
def get_active_application():
return get_active_object(_progid_)
def get_documents():
return get_active_application().Documents
if __name__ == '__main__':
docs = get_documents()
#print docs[1].FullName # This line causes AttributeError:
# 'tuple' object has no attribute 'FullName'
print docs[1] # returns (Microsoft.Office.Interop.Word.DocumentClass, 1)
print docs[2] # returns (Microsoft.Office.Interop.Word.DocumentClass, 2)
print docs[1][0].FullName
This is the code that i tested. For the last couple of lines, i was
expecting that
docs[1] and docs[2] would return the document object instead of a
tuple with the first of its item being the document. Is this the
intended behavior?
Thank you,
--
Kelie
___
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] Good example of with statement usage in IronPython/COM
There was a leak in IronPython where we were keeping COM objects alive once the IPy code manipulated the COM object. The code in the blog seems to be dealing with this bug with the use of the auto method which calls Marshal.ReleaseComObject in the finally. The bug is fixed in the 2.0 tree and so it should be possible to shorten the code a lot and end up with just a few levels of nesting. Shri -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo Sent: Saturday, October 27, 2007 8:10 PM To: Discussion of IronPython Subject: [IronPython] Good example of with statement usage in IronPython/COM I found this interesting blog post which has a good example of with statement (Python 2.5 feature) usage in IronPython/COM. http://d.hatena.ne.jp/akiramei/20071026/1193419839 It's written in Japanese, but the code speaks for itself. The last line would translate to something like It's getting shorter, but nesting is a bit too deep... -- Seo Sanghyeon ___ 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] Good example of with statement usage in IronPython/COM
Well, still a good use of with for an elegant workaround :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo Sent: Saturday, October 27, 2007 10:44 PM To: Discussion of IronPython Subject: Re: [IronPython] Good example of with statement usage in IronPython/COM 2007/10/28, Shri Borde [EMAIL PROTECTED]: There was a leak in IronPython where we were keeping COM objects alive once the IPy code manipulated the COM object. The code in the blog seems to be dealing with this bug with the use of the auto method which calls Marshal.ReleaseComObject in the finally. The bug is fixed in the 2.0 tree and so it should be possible to shorten the code a lot and end up with just a few levels of nesting. Oops, it was a bug then. -- Seo Sanghyeon ___ 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] Hosting APIs walkthrough document
http://compilerlab.members.winisp.net/hosting-tour.doc has a good walk through of the hosting APIs in IPy 2.0. It may be a little out of sync with the current sources, but its still a very good source of information. There have been questions on using the hosting APIs, and this should help with getting started. Thanks, Shri ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)
I have attached a sample at the bottom of http://msdn2.microsoft.com/en-us/library/system.threading.executioncontext.aspx showing how state can be automatically propagated across thread boundaries. You should be able to set the desired output stream for each thread processing your data. Even if user code spawns new thread, the output stream information can automatically be propagated to the children thread. Would this work for you? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fuzzyman Sent: Tuesday, June 05, 2007 1:30 AM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Shri Borde wrote: Michael, how does multiple engines help you when several pieces of user-code are running concurrently? It seems that if you are willing to live with some restrictions (like every thread having a single output stream), you should be able to live without multiple engines. We could make this easier by formalizing this design pattern, but you may be able to achieve your required semantics of only redirecting stdout without that. The users may have several user interface windows open at one time, each relating to a different data-set. Although only one window is 'active', several can be processing data at the same time - and executing user code as a result. Each window has an IronPython engine associated with it, in which the data-sets are processed. This way output from each data-set goes to its window. User code *can* spin off new threads if they want, but because they are executing 'inside' their engines - output goes to the right place. If you can suggest a way we can achieve this without multiple engines, then we are interested. All the best, Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml We have not finalized on the single engine story yet, but we are leaning towards it at the moment. Shri Borde said: Have you looked at moving to 2.0? Dino had mentioned a workaround (of maintaining a thread-local static) which would enable you to selectively redirect console output. Given that you are running into a number of issues and that you might have a stream of such issues going forward, it will be hard for us to continually port all those fixes to 1.1. Michael Foord said: That is the problem: if we have several pieces of user-code running concurrently then we wouldn't know which output stream it belonged to. (If we only had one stream at a time we could override sys.stdout from the Python side.) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Wednesday, May 02, 2007 1:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Both you and Tony bring up a very good point. I believe that we can solve the thread problem by using .NET's ExecutionContext. I've never actually tried that, I just know it exists, so I'll need to look into that. That will cause the context to be flown to thread pool threads, newly created threads, and other various async points within the CLR. One reason for its existence today is for security so the CLR is pretty good at making sure this always gets flowed (there are various ways to do operations which don't flow it, but they all have Unsafe in their name). Based upon Tony's description of I'm starting to believe the swappable SystemStates rather than multiple PythonEngines are the right solution - especially given that CPython is using a similar technique and even more so if ExecutionContext solves the async/threading problem. Thanks for all your feedback and let me know if you have any more. I'll take it all to our discussion about the hosting APIs next week. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Wednesday, May 02, 2007 12:19 PM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Dino Viehland wrote: I didn't even realize posting at the top was considered a no-no on mailing list etiquette... But indeed, I am using Outlook. I wonder if there's an option to change that somewhere... I was a bit tongue in cheek - but top-posting suffers from the same readability issues on mailing lists as it does in usenet posts. Thanks for your feedback Michael. This thread has diverged a little bit so let me know if you have any thoughts on the rest of it. It occurs to me that your suggestion won't work for us if the user spawns any threads of their own (which is highly likely) - unless we can tell what thread it was spawned from... Meanwhile I'll try and digest the rest of *this* thread... Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED
Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)
I agree that you should stick with 1.1 if you are close to release. We will fix critical blocking bugs in 1.1 as needed. However, to keep that branch stable, the bar will be high. Do shout if you run into blocking issues. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fuzzyman Sent: Tuesday, June 05, 2007 2:30 AM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Shri Borde said: Have you looked at moving to 2.0? Dino had mentioned a workaround (of maintaining a thread-local static) which would enable you to selectively redirect console output. Given that you are running into a number of issues and that you might have a stream of such issues going forward, it will be hard for us to continually port all those fixes to 1.1. None of the 1.1 bugs are blocking us, we have just discovered them as we develop. If we encounter a blocking bug we will shout loudly. :-) Given that we are so close to release, and that switching to 2.0 will mean non-trivial changes (which wasn't true of 1.0 - 1.1 - thank you), we will stick to 1.1 for the moment. Eventually we will have to move to 2.0 of course (and would like to). As 2.0 is still in alpha, we would like to think that the 1.X branch hasn't been abandoned by 'the team'. In the very long run we will move to executing user code inside appdomains, but currently that would result in a lot of cross domain calls that would hurt our performance in a big way. As resolving this would be a lot of work it isn't yet a high priority for us - and won't be for quite a long time. All the best, Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml ___ 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] Backporting of bugs to 1.1
We are focusing most of our efforts on the 2.0 branch and the DLR. We are not automatically backporting bug fixes to 1.1. We will consider doing that for specific bugs based on priority and how much it affects customers. However, given our limited resources and wanting to keep 1.1 as stable as possible, our preference is to minimize development in the 1.1 branch and focus on the 2.0 branch. Have you looked at moving to 2.0? Dino had mentioned a workaround (of maintaining a thread-local static) which would enable you to selectively redirect console output. Given that you are running into a number of issues and that you might have a stream of such issues going forward, it will be hard for us to continually port all those fixes to 1.1. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, June 04, 2007 8:46 AM To: Discussion of IronPython Subject: [IronPython] __doc__ on None Hello all, More fun with None: CPython 2.4.4: print None.__doc__ None IP 1.1: print None.__doc__ T.__new__(S, ...) - a new object with type S, a subtype of T This is again confusing our auto-documentation tool. :-) By the way - can any of 'the team' answer the question as to whether the 1.1 branch is still being developed? (Bugfixes being backported?) Thanks Michael Foord -- Michael Foord Resolver Systems [EMAIL PROTECTED] Office address: 17a Clerkenwell Road, London EC1M 5RD, UK Registered address: 843 Finchley Road, London NW11 8NA, UK Resolver Systems Limited is registered in England and Wales as company number 5467329. VAT No. GB 893 5643 79 ___ 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] Backporting of bugs to 1.1
Could you check if the thread-local static was null (uninitialized), infer that that this was a new user-created thread, and then initialize the static to the output stream you wanted for that thread? We can investigate the perf degrade of IPy 2.0 on .NET 3. I can't say if we can fix it completely until we do some investigations, but this is something that we would like to invest in anyway. Btw, did you say you are not willing to depend on .NET 3 or did you mean you are not willing to depend on IPy 2.0? When are you planning on releasing your product? (You could reply just to me if you want). We can use this as input to our decision on our servicing plans for 1.1. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, June 04, 2007 10:05 AM To: Discussion of IronPython Subject: Re: [IronPython] Backporting of bugs to 1.1 Shri Borde wrote: We are focusing most of our efforts on the 2.0 branch and the DLR. We are not automatically backporting bug fixes to 1.1. We will consider doing that for specific bugs based on priority and how much it affects customers. However, given our limited resources and wanting to keep 1.1 as stable as possible, our preference is to minimize development in the 1.1 branch and focus on the 2.0 branch. Have you looked at moving to 2.0? Dino had mentioned a workaround (of maintaining a thread-local static) which would enable you to selectively redirect console output. Given that you are running into a number of issues and that you might have a stream of such issues going forward, it will be hard for us to continually port all those fixes to 1.1. We need to divert standard output to capture output from user code. If user code uses threads (which it can do) - then the thread-local idea won't work. Also on systems with .NET 3, there is a reported speed degradation moving from 1 to 2, which we can't afford (and we aren't willing to depend on .NET 3 yet I'm afraid). All the best, Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, June 04, 2007 8:46 AM To: Discussion of IronPython Subject: [IronPython] __doc__ on None Hello all, More fun with None: CPython 2.4.4: print None.__doc__ None IP 1.1: print None.__doc__ T.__new__(S, ...) - a new object with type S, a subtype of T This is again confusing our auto-documentation tool. :-) By the way - can any of 'the team' answer the question as to whether the 1.1 branch is still being developed? (Bugfixes being backported?) Thanks Michael Foord -- Michael Foord Resolver Systems [EMAIL PROTECTED] Office address: 17a Clerkenwell Road, London EC1M 5RD, UK Registered address: 843 Finchley Road, London NW11 8NA, UK Resolver Systems Limited is registered in England and Wales as company number 5467329. VAT No. GB 893 5643 79 ___ 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 ___ 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] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released)
Michael, how does multiple engines help you when several pieces of user-code are running concurrently? It seems that if you are willing to live with some restrictions (like every thread having a single output stream), you should be able to live without multiple engines. We could make this easier by formalizing this design pattern, but you may be able to achieve your required semantics of only redirecting stdout without that. We have not finalized on the single engine story yet, but we are leaning towards it at the moment. Shri Borde said: Have you looked at moving to 2.0? Dino had mentioned a workaround (of maintaining a thread-local static) which would enable you to selectively redirect console output. Given that you are running into a number of issues and that you might have a stream of such issues going forward, it will be hard for us to continually port all those fixes to 1.1. Michael Foord said: That is the problem: if we have several pieces of user-code running concurrently then we wouldn't know which output stream it belonged to. (If we only had one stream at a time we could override sys.stdout from the Python side.) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Wednesday, May 02, 2007 1:48 PM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Both you and Tony bring up a very good point. I believe that we can solve the thread problem by using .NET's ExecutionContext. I've never actually tried that, I just know it exists, so I'll need to look into that. That will cause the context to be flown to thread pool threads, newly created threads, and other various async points within the CLR. One reason for its existence today is for security so the CLR is pretty good at making sure this always gets flowed (there are various ways to do operations which don't flow it, but they all have Unsafe in their name). Based upon Tony's description of I'm starting to believe the swappable SystemStates rather than multiple PythonEngines are the right solution - especially given that CPython is using a similar technique and even more so if ExecutionContext solves the async/threading problem. Thanks for all your feedback and let me know if you have any more. I'll take it all to our discussion about the hosting APIs next week. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Wednesday, May 02, 2007 12:19 PM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) Dino Viehland wrote: I didn't even realize posting at the top was considered a no-no on mailing list etiquette... But indeed, I am using Outlook. I wonder if there's an option to change that somewhere... I was a bit tongue in cheek - but top-posting suffers from the same readability issues on mailing lists as it does in usenet posts. Thanks for your feedback Michael. This thread has diverged a little bit so let me know if you have any thoughts on the rest of it. It occurs to me that your suggestion won't work for us if the user spawns any threads of their own (which is highly likely) - unless we can tell what thread it was spawned from... Meanwhile I'll try and digest the rest of *this* thread... Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Wednesday, May 02, 2007 9:06 AM To: Discussion of IronPython Subject: Re: [IronPython] Multiple engine instances in IP 2.0 and beyond (was IronPython 2.0 Alpha 1 Released) My guess is that you have to use outlook. It does seem to encourage top-posting. ;-) Dino Viehland wrote: The scripts are running on multiple threads? Usually - although sometimes code is executed on the GUI thread, but in this case we always know where to send the output. The easy way to do this in v2.0 is to set console output (we no longer maintain our own output streams) to be a stream which looks at a thread static variable which is the real stream to output to. Would that solve the entire isolation problem for you? Our current code is nice and elegant, whilst yours sounds hacky. :-p Actually its just a solution we didn't think of, although it isn't quite as nice as running them in separate engines which we do now, and does give us *some* measure of isolation. (It is slightly less likely that a badly written user script will now kill the whole application, although obviously still very easy.) The only problem w/ this is if user code sets sys.stdout they'll hijack all the other scripts. Which is a problem - but we can always say don't do that then... I think we still like our current use of multiple engines, and would prefer to see that supported in IronPython 2.0, even
Re: [IronPython] Using CLR bound COM interfaces
Using isinstance should be the right way to check if an object is an interface.
However, this does not currently work.
http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPythonWorkItemId=8121
tracks this issue. The (admittedly ugly) workaround that is also mentioned in
the bug is:
import clr
import System
isinstance(1, System.IFormattable) # Should return True
False
clr.GetClrType(System.IFormattable).IsAssignableFrom(clr.GetClrType(type(1)))
# Workaround
True
For your second question, the answer depends on the actual type (not the
statically declared C# type) of geometryDef. If it implements
IGeometryDefEdit explicitly, you do need to use
IGeometryDefEdit.MethodName(geometryDef, args). Else, you can just use
geometryDef. MethodName(args). The following bugs are related.
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=4538
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=1506
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Willmer
Sent: Sunday, February 25, 2007 5:36 PM
To: users@lists.ironpython.com
Subject: [IronPython] Using CLR bound COM interfaces
Hello,
I've been attempting with IronPython, to access the CLR binding to
ArcObjects[1], a COM based Geographic Information System (GIS) library.
I come at this from a CPython background, so my knowledge of COM .NET
are lacking.
I'm trying to understand how interfaces (IFoobar) are dealt with in
IronPython. A C# example I'm attempting to transcribe contains the
following lines:
if (!((objectWorkspace is IWorkspace) ||
(objectWorkspace is IFeatureDataset)))
{
throw(new Exception());
}
My assumption was that isinstance() would replace 'is', but the
following would indicate otherwise. From the .NET 2.0 docs[2] the
System.Uri class inherits from ISerializable
import System
import System.Runtime.Serialization
x = System.Uri('http://example.net')
isinstance(x, System.Uri)
True
isinstance(x, System.Runtime.Serialization.ISerializable)
False
How should I test a particular object implements an interface?
My second query is based on the following C#:
IGeometryDefEdit geometryDefEdit = (IGeometryDefEdit) geometryDef;
// Assign Geometry Definition
geometryDefEdit.GeometryType_2 = geometryType;
geometryDefEdit.GridCount_2 = 1;
geometryDefEdit.set_GridSize(0, 0.5);
geometryDefEdit.AvgNumPoints_2 = 2;
geometryDefEdit.HasM_2 = false;
geometryDefEdit.HasZ_2 = true;
I understand that to transcribe this is I should forget the
assignment/cast and replace geometryDefEdit.Method(args) with
IGeometryDefEdit.MethodName(geometryDef, args). Is this correct?
Many thanks.
Alex Willmer
[1] http://edndoc.esri.com/arcobjects/9.1/
[2] http://msdn2.microsoft.com/en-us/library/system.uri.aspx
___
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] Calling Methods from other Methods
This is quite non-intuitive, but it is by-design. It is happening because of
using a locals dictionary which is different than the globals dictionary. Note
that top-level code in a .py file executes with the same locals and globals
dictionary.
The following Python snippet shows that a similar issue exists in pure Python
code. func1 and func2 get assigned in the locals dictionary. When executing
func2, the global dictionary is looked up, and it does not have func1.
g={}
l={}
functions=def func1(): print 'func1'
... def func2(): func1()
... func2()
...
exec(functions, g, l)
Traceback (most recent call last):
File stdin, line 1, in ?
File string, line 3, in ?
File string, line 2, in func2
NameError: global name 'func1' is not defined
l
{'func2': function func2 at 0x01D285F0, 'func1': function func1 at
0x01D28930}
The following snippet shows how you can achieve what you are trying to do. The
takeaway is that if you use a locals dicitionary different than the globals
dictionary, you have to explicitly declare your global variables so that they
get assigned in the globals dictionary.
g={}
l={}
functions=global func1
... global func2
...
... def func1(): print 'func1'
... def func2(): func1()
... func2()
...
exec(functions, g, l)
func1
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Fugate
Sent: Wednesday, December 20, 2006 4:33 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Calling Methods from other Methods
Thanks Ken!
Looks like a bug to me and I've filed a CodePlex Work Item (see
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=6714).
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of kenj55
Sent: Tuesday, December 19, 2006 9:39 AM
To: users@lists.ironpython.com
Subject: [IronPython] Calling Methods from other Methods
Hi,
I'm having a problem calling one method from another when i run python
within the PythonEngine.
i.e. If I have the following code:
string functions = def func1():\n\treturn \hello\\n\n;
functions += def func2():\n\treturn func1()\n\n;
functions += func2();
pyEngine.Execute(functions, module, locals);
I get an error along the lines of:
IronPython.Runtime.Exceptions.PythonNameErrorException: name 'func1' not
defined
Does anyone have any ideas where I might be going wrong?
Cheers,
Ken
--
View this message in context:
http://www.nabble.com/Calling-Methods-from-other-Methods-tf2847245.html#a7951284
Sent from the IronPython mailing list archive at Nabble.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
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] embedded debugging
We do want to provide a good debugging experience, but we will not be able to get to this in the short term. The VSIP integration is currently a sample. Making it support all functionality is a fair bit of work. http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPythonWorkItemId=2539 tracks this issue. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Ivan Chelubeev [EMAIL PROTECTED] Sent: Monday, November 27, 2006 8:19 AM To: Discussion of IronPython Subject: Re: [IronPython] embedded debugging Shri Borde wrote: I believe your breakpoint is in top-level global code of the module. In that case, this is a known limitation. What is needed is a visualizer to display CLR global variables. VisualStudio does support such a plug-in architecture. However, such a plug-in has not yet been implemented. We do want to improve such support in the future, but we have not gotten to this yet. Are there any plans to do this anytime soon? ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] embedded debugging
I believe your breakpoint is in top-level global code of the module. In that case, this is a known limitation. VisualStudio will display local variables of functions defined in IronPython. However, if you are executing top-level global code, the Python global variables are implemented as CLR static variables or sometimeas as a dictionary object held in a CLR static variable. The Locals window in VisualStudio does not display CLR global variables. As a result, you will not see the Python global variables. What is needed is a visualizer to display CLR global variables. VisualStudio does support such a plug-in architecture. However, such a plug-in has not yet been implemented. We do want to improve such support in the future, but we have not gotten to this yet. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Moore Sent: Wednesday, November 08, 2006 10:12 AM To: users@lists.ironpython.com Subject: [IronPython] embedded debugging I have an app that embedds IP runtime. I can set break points in the IP code but the debugger does not show any variables. The only variable is $line. All I can do is step through the code. I have set the debuggable option on the engine It is using CompiledCode ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
[IronPython] New - PythonEngine documentation
In case you hadnt noticed, there is a new IronPythonApiReference.chm in the Doc folder in the zip 1.0 RTM zip files, both bin and src. This should help answer many of the questions which come up about the specifics of the hosting APIs. Thanks, Shri PS: I thought I had sent this email earlier but didnt see it on the mailing list. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] if __name__ == '__main__' broken in RC2?
The main motivation was to not make policy decisions for the host. The host may or may not want sys.modules[__main__] to exist. We leave it up to the host to do whatever is right for its scenario. For eg, ipy.exe foo.py does not use the default module, and instead creates a new OptimizedEngineModule and publishes that as __main__. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jesse Wiles Sent: Wednesday, August 30, 2006 4:26 PM To: Discussion of IronPython Subject: Re: [IronPython] if __name__ == '__main__' broken in RC2? OK. So, I think I get the how, but I don't understand the why. If I execute a python file using PythonEngine.Execute(), why doesn't it just do the right thing? Why do I have to instruct the embedded engine to behave like the CPython implementation. Why doesn't it just do it? Shri Borde wrote: pythonEngine.Execute(print __name__) is exactly the same as doing pythonEngine.Execute(print __name__, pythonEngine.DefaultModule). The issue is that the name of pythonEngine.DefaultModule is not __main__. Also, it is not published in sys.modules since its upto the host to determine which modules are published and which are not. So you would need to do the following for it to print __main__. bool shouldPublishMainModule; // You get to chose what this value should be. It should probably be true for __main__. EngineModule mainModule = pythonEngine.CreateModule(__main__, shouldPublishMainModule); pythonEngine.Execute(print __name__, mainModule) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dino Viehland Sent: Wednesday, August 30, 2006 8:49 AM To: Discussion of IronPython Subject: Re: [IronPython] if __name__ == '__main__' broken in RC2? We havent had any other reports of issues like this so well need some more details. Are you creating a module named __main__ ? (the console creates an engine named __main__, but if youre using the engine directly we never create a __main__ module for you). How is it not evaluating properly? Are we thinking were in main or not in main? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jesse Wiles Sent: Wednesday, August 30, 2006 7:51 AM To: Discussion of IronPython Subject: [IronPython] if __name__ == '__main__' broken in RC2? Hi, I'm running into a problem where if __name__ == '__main__' is not evaluating properly when using PythonEngine from my assembly. Is this a known issue? Thanks, Jesse Wiles ___users mailing listusers@lists.ironpython.comhttp://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] Debugging support PythonEngine
We do actually run all our tests using both DynamicMethods and AssemblyBuilder. This has helped us catch bugs in the DynamicMethods implementation. If there is any difference, it is a bug that should be fixed. Running ipy.exe foo.py will use the AssemblyBuilder, so that code path is used heavily. In fact, more than DynamicMethods. The IL generation is actually unaware of whether the method is a DynamicMethod or a MethodBuilder. So there should not be any differences. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of J. Merrill Sent: Thursday, August 17, 2006 9:44 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging support PythonEngine Without looking at the IP source, can we be confident that the same IL is produced when a DynamicMethod is created as when AssemblyBuilder is used? Do the test cases get run with both settings of Options.GenerateDynamicMethods? One of the most frustrating debugging problems is when code fails when running normally, but works when attempting to debug, due to the code being generated differently in the two situations. I have not heard anyone else worry out loud that e.g. the code running when using the console seems to be different than what is obtained using the IronPython.Compiler, etc. How concerned should we be when we learn that the code paths are very different? At 05:49 PM 8/17/2006, Shri Borde wrote The first issue is probably the same that IL offset 0 does not have any debug information. Calling the delegate ?add? steps into a DynamicMethod which confuses VS. A workaround for now is to add this statement before creating the PythonEngine. IronPython.Compiler.Options.GenerateDynamicMethods = false; This disabled the use of DynamicMethods altogether and will instead use AssemblyBuilder. This is not generally recommended or supported since you are going to leak memory since AssemblyBuilder memory cannot be reclaimed. However, VS seems to be better able to deal with AssemblyBuilder during stepping, and it might be good enough for you. This is a case where we will would need to teach the tool (VS) to handle DynamicMethods differently than it currently does. [snip] J. Merrill / Analytical Software Corp ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Debugging support PythonEngine
Setting ClrDebuggingEnabled = true will only leak memory for the code executed using the PythonEngine.ExecuteFile API. Any other evals done by other Python modules that are loaded in the engine (using the import command) and code executed using PythonEngine.Evaluate or PythonEngine.Execute will still DynamicMethods. However, setting with IronPython.Compiler.Options.GenerateDynamicMethods = false will use AssemblyBuilder for those cases too, and so will leak more memory. We are working on providing documentation for PythonEngine. For now, the answer is simply that memory used by System.Reflection.Emit.AssemblyBuilder, MethodBuilder, etc. can not be reclaimed whereas memory used by System.Reflection.Emit.DynamicMethod can be reclaimed From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Thursday, August 17, 2006 11:43 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] Debugging support PythonEngine Leaking memory with IronPython.Compiler.Options.GenerateDynamicMethods = false isnt really a big issue: ClrDebuggingEnabled = true already starts to leak memory (at least thats what the comment says). Is there any complete documentation about what actions cause memory leaks? By following this mailing list and looking at the source code comments I know of some things, but Im sure that I dont know all situations. Maybe it would be a good idea to have a setting AllowMemoryLeaks which has a default of false. Whenever you go through a code path that is going to leak memory through code generation you could throw an exception. This way, you know at least that something youre doing is wrong. If youre OK with the memory leak, then you could set AllowMemoryLeaks to true. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Thursday 17 August 2006 23:49 To: Discussion of IronPython Subject: Re: [IronPython] Debugging support PythonEngine The first issue is probably the same that IL offset 0 does not have any debug information. Calling the delegate add steps into a DynamicMethod which confuses VS. A workaround for now is to add this statement before creating the PythonEngine. IronPython.Compiler.Options.GenerateDynamicMethods = false; This disabled the use of DynamicMethods altogether and will instead use AssemblyBuilder. This is not generally recommended or supported since you are going to leak memory since AssemblyBuilder memory cannot be reclaimed. However, VS seems to be better able to deal with AssemblyBuilder during stepping, and it might be good enough for you. This is a case where we will would need to teach the tool (VS) to handle DynamicMethods differently than it currently does. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Debugging support PythonEngine
I have opened this bug - http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPythonWorkItemId=2248 - to track the issue with stepping in. We are not emitting any line number information for IL offset 0. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Wednesday, August 16, 2006 12:29 PM To: Discussion of IronPython Subject: Re: [IronPython] Debugging support PythonEngine We have started doing some work for improving debugging as shown by the VSIP sample (http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx). However, it still needs more work for it to be production-quality. By tools support, I was referring more to VSIP sample. We dont have a concrete timeline for when we will be able to improve it further. Btw, using your sample script below, in most cases, I am able to step from Python code into C# code in IronPython.dll if I hit F11 in VS. However, when IronPython.dll calls the method Add, we step into native code for a while before actually reaching the source code for Add. This looks like something we can fix by changing the debug information we generate. After doing this fix, it would be possible to mark IronPython.dll as library code (either using DebuggerNonUserCodeAttribute or through some other scheme), and be able to step from Python code into a Python method. x = 1 y = 2 def Add(a, b): return a + b z = Add(x, y) ß Stepping in here takes you to IronPython.dll source code, then native code, and then the source code for Add print z From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Saturday, August 12, 2006 1:38 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] Debugging support PythonEngine Thanks for the info. Its good to hear that there will be improvement possible in this area in the future. Although, the way I interpret your explanation, its not going to be anytime soon (or even this year), because you need enhancements to the underlying platform to make this possible. Ive experimented a bit with System.Diagnostics.DebuggerNonUserCodeAttribute to see if it wasnt possible to skip stepping into IronPython code. Unfortunately, the point where I get stuck in the assembly instructions is in generated code. I dont understand this part of the code well enough to know if its possible to make the debugger skip these lines. Maybe this is why you need the changes to the platform? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Friday 11 August 2006 21:04 To: Discussion of IronPython Subject: Re: [IronPython] Debugging support PythonEngine Yes, we will definitely be working on improving the debugging support as it is a critical part of the development process. However, full support will need work in all parts of the tool chain including VS. Python local variables are implemented as normal MSIL variables (except in cases like closures). Hence, VS is able to display them. Currently, the best way to debug Python functions in VS while using PythonEngine would be to enable EngineOptions.ClrDebuggingEnable, open the PY file in VS and put a breakpoint where you want. Stepping in and out of Python functions will step you through methods in IronPython.dll . From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Friday, August 11, 2006 12:36 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] Debugging support PythonEngine Are there plans to improve the debugging experience in the future or are you at a point where it is as good as it gets? Being able to debug makes writing and using python scripts a lot easier. Inside functions I can see not only the function parameters but also the newly defined local variables. Are these different from the global variables? I would have expected that the function locals are also stored inside a dictionary. Is it possible to step into python functions without getting into assembly instructions? This is very frustrating and degrades the debugging experience a lot. This is the more important issue for me. Im not going to be using global variables frequently, but mostly functions loaded in the PythonEngine that are called from C#. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Friday 11 August 2006 0:30 To: Discussion of IronPython Cc: Glenn Hackney Subject: Re: [IronPython] Debugging support PythonEngine If EngineOptions.ClrDebuggingEnabled is set, we use AssemblyBuilder, TypeBuilder, etc for PythonEngine.Executed. The code generated by AssemblyBuilder, TypeBuilder, etc supports PDB debug information tracking for the methods, and so you will be able to set breakpoints in the code. However, it does not guarantee a perfect debugging experience. PythonEngine.ExecuteFile will use a dictionary for storing global variables, and these will not be visible because VS does not know about
Re: [IronPython] Debugging support PythonEngine
The first issue is probably the same that IL offset 0 does not have any debug information. Calling the delegate add steps into a DynamicMethod which confuses VS. A workaround for now is to add this statement before creating the PythonEngine. IronPython.Compiler.Options.GenerateDynamicMethods = false; This disabled the use of DynamicMethods altogether and will instead use AssemblyBuilder. This is not generally recommended or supported since you are going to leak memory since AssemblyBuilder memory cannot be reclaimed. However, VS seems to be better able to deal with AssemblyBuilder during stepping, and it might be good enough for you. This is a case where we will would need to teach the tool (VS) to handle DynamicMethods differently than it currently does. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Thursday, August 17, 2006 1:54 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] Debugging support PythonEngine Its good to hear that its fixable. But, off course, heres the next one J. With the same little script: x = 1 y = 2 def Add(a, b): x = a + b return x z = Add(x, y) print z And the following C# code: EngineOptions options = new EngineOptions(); options.ClrDebuggingEnabled = true; PythonEngine _pe = new PythonEngine(options); delegate int Add(int a, int b); _pe.ExecuteFile(@ script path ); Add add = _pe.EvaluateAsAdd(Add); int var1 = add(2, 3); int var2 = add(3, 4); The following happens: (I use a release version of Ironpython (RC2). There are no debug symbols present, so that I dont step into the engine code.) I step into ExecuteFile (F11) and get into native code. After a few lines of native code, I can go back to the source code view and Im in the Python script file. Maybe this is a similar issue as with stepping into a function? Next, I get a delegate to the Python Add function. The first time I step into the add delegate I get the stepping into a function problem and then Im inside the function. But, when I try to step into the next add delegate this doesnt work anymore: the line is marked in green in Visual Studio and I remain in the C# code. The next step into command resumes on the next line in the C# code. I cant see a reason why it would fail with the next add. Setting a breakpoint in the Python function stops the execution at that point in both cases. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Thursday 17 August 2006 20:25 To: Discussion of IronPython Subject: Re: [IronPython] Debugging support PythonEngine I have opened this bug - http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPythonWorkItemId=2248 - to track the issue with stepping in. We are not emitting any line number information for IL offset 0. ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] expose some namespaces of own application
Could you use mark the types as internal and public depending on whether you
wanted to prevent or allow access from IronPython? IronPython code will not be
able to access types or methods marked as internal in your C# code.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Tuesday, August 15, 2006 8:09 AM
To: Discussion of IronPython
Subject: Re: [IronPython] expose some namespaces of own application
It is currently an all-or-nothing situation. As a work around you could create
your own module (import imp.new_module('modulename')) and then you could add
the namespaces onto the new module, then publish the module in sys.modules:
import imp
import sys
mod = imp.new_module('test')
mod.abc = 'xyz'
sys.modules['test'] = mod
import test
print test.abc
You can do this w/o giving IronPython the reference to your assembly. Just
load the assembly, and from Python you can access the namespaces/types directly
off the assembly object.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stanislas Pinte
Sent: Tuesday, August 15, 2006 12:34 AM
To: Discussion of IronPython
Subject: [IronPython] expose some namespaces of own application
Hello,
We are using IP as a scripting engine, embedded in one of our products.
I would like to be able to expose a subset of the namespaces present in my
application assembly (MyApp.exe) to the scripting engine...but hide the rest:
i.e. when a user does an from a.b.c import Bar, if a.b.c is hidden, then it
fails:
from a.b.c import Bar
Traceback (most recent call last):
File stdin, line 1, in ?
ImportError: No module named a.b.c
whereas if a.b.pub has been exposed to the scripting engine, then the user
can import it.
Is this currently possible? I have the impression that it is an all-or-nothing
situation...and I would like to avoid having to split my classes in several
assemblies.
Thanks for all input,
Kind regards,
Stan.
--
-
Stanislas Pinte e-mail: [EMAIL PROTECTED]
ERTMS Solutions http://www.ertmssolutions.com
Rue de l'Autonomie, 1 Tel:+ 322 - 522.06.63
1070Bruxelles Fax: + 322 - 522.09.30
-
Skype (http://www.skype.com) id: stanpinte
-
___
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
___
users mailing list
users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Debugging support PythonEngine
We have started doing some work for improving debugging as shown by the VSIP sample (http://blogs.msdn.com/aaronmar/archive/2006/02/16/533273.aspx). However, it still needs more work for it to be production-quality. By tools support, I was referring more to VSIP sample. We dont have a concrete timeline for when we will be able to improve it further. Btw, using your sample script below, in most cases, I am able to step from Python code into C# code in IronPython.dll if I hit F11 in VS. However, when IronPython.dll calls the method Add, we step into native code for a while before actually reaching the source code for Add. This looks like something we can fix by changing the debug information we generate. After doing this fix, it would be possible to mark IronPython.dll as library code (either using DebuggerNonUserCodeAttribute or through some other scheme), and be able to step from Python code into a Python method. x = 1 y = 2 def Add(a, b): return a + b z = Add(x, y) Stepping in here takes you to IronPython.dll source code, then native code, and then the source code for Add print z From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Saturday, August 12, 2006 1:38 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] Debugging support PythonEngine Thanks for the info. Its good to hear that there will be improvement possible in this area in the future. Although, the way I interpret your explanation, its not going to be anytime soon (or even this year), because you need enhancements to the underlying platform to make this possible. Ive experimented a bit with System.Diagnostics.DebuggerNonUserCodeAttribute to see if it wasnt possible to skip stepping into IronPython code. Unfortunately, the point where I get stuck in the assembly instructions is in generated code. I dont understand this part of the code well enough to know if its possible to make the debugger skip these lines. Maybe this is why you need the changes to the platform? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Friday 11 August 2006 21:04 To: Discussion of IronPython Subject: Re: [IronPython] Debugging support PythonEngine Yes, we will definitely be working on improving the debugging support as it is a critical part of the development process. However, full support will need work in all parts of the tool chain including VS. Python local variables are implemented as normal MSIL variables (except in cases like closures). Hence, VS is able to display them. Currently, the best way to debug Python functions in VS while using PythonEngine would be to enable EngineOptions.ClrDebuggingEnable, open the PY file in VS and put a breakpoint where you want. Stepping in and out of Python functions will step you through methods in IronPython.dll . From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Friday, August 11, 2006 12:36 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] Debugging support PythonEngine Are there plans to improve the debugging experience in the future or are you at a point where it is as good as it gets? Being able to debug makes writing and using python scripts a lot easier. Inside functions I can see not only the function parameters but also the newly defined local variables. Are these different from the global variables? I would have expected that the function locals are also stored inside a dictionary. Is it possible to step into python functions without getting into assembly instructions? This is very frustrating and degrades the debugging experience a lot. This is the more important issue for me. Im not going to be using global variables frequently, but mostly functions loaded in the PythonEngine that are called from C#. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Friday 11 August 2006 0:30 To: Discussion of IronPython Cc: Glenn Hackney Subject: Re: [IronPython] Debugging support PythonEngine If EngineOptions.ClrDebuggingEnabled is set, we use AssemblyBuilder, TypeBuilder, etc for PythonEngine.Executed. The code generated by AssemblyBuilder, TypeBuilder, etc supports PDB debug information tracking for the methods, and so you will be able to set breakpoints in the code. However, it does not guarantee a perfect debugging experience. PythonEngine.ExecuteFile will use a dictionary for storing global variables, and these will not be visible because VS does not know about the dictionary. If you use PythonEngine.CreateOptimizedModule, most global variables are implemented using CLR statics, and so VS may be able to display them for you. Global variables added using an exec statement will still not be visible. If EngineOptions.ClrDebuggingEnabled is false, we will use System.Reflection.Emit.DynamicMethod. This does not support debug information tracking at all, and you will not even be able
Re: [IronPython] Debugging support PythonEngine
Yes, we will definitely be working on improving the debugging support as it is a critical part of the development process. However, full support will need work in all parts of the tool chain including VS. Python local variables are implemented as normal MSIL variables (except in cases like closures). Hence, VS is able to display them. Currently, the best way to debug Python functions in VS while using PythonEngine would be to enable EngineOptions.ClrDebuggingEnable, open the PY file in VS and put a breakpoint where you want. Stepping in and out of Python functions will step you through methods in IronPython.dll . From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Friday, August 11, 2006 12:36 AM To: 'Discussion of IronPython' Subject: Re: [IronPython] Debugging support PythonEngine Are there plans to improve the debugging experience in the future or are you at a point where it is as good as it gets? Being able to debug makes writing and using python scripts a lot easier. Inside functions I can see not only the function parameters but also the newly defined local variables. Are these different from the global variables? I would have expected that the function locals are also stored inside a dictionary. Is it possible to step into python functions without getting into assembly instructions? This is very frustrating and degrades the debugging experience a lot. This is the more important issue for me. Im not going to be using global variables frequently, but mostly functions loaded in the PythonEngine that are called from C#. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Friday 11 August 2006 0:30 To: Discussion of IronPython Cc: Glenn Hackney Subject: Re: [IronPython] Debugging support PythonEngine If EngineOptions.ClrDebuggingEnabled is set, we use AssemblyBuilder, TypeBuilder, etc for PythonEngine.Executed. The code generated by AssemblyBuilder, TypeBuilder, etc supports PDB debug information tracking for the methods, and so you will be able to set breakpoints in the code. However, it does not guarantee a perfect debugging experience. PythonEngine.ExecuteFile will use a dictionary for storing global variables, and these will not be visible because VS does not know about the dictionary. If you use PythonEngine.CreateOptimizedModule, most global variables are implemented using CLR statics, and so VS may be able to display them for you. Global variables added using an exec statement will still not be visible. If EngineOptions.ClrDebuggingEnabled is false, we will use System.Reflection.Emit.DynamicMethod. This does not support debug information tracking at all, and you will not even be able to see function variables. So If EngineOptions.ClrDebuggingEnabled is will improve your debugging experience, but it wont give you a perfect experience. Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kristof Wagemans Sent: Thursday, August 10, 2006 2:10 PM To: Discussion of IronPython Subject: [IronPython] Debugging support PythonEngine I have been experimenting with the debugging support for the PythonEngine. When I use the following code I have several problems. PythonEngine _pe; EngineOptions options = new EngineOptions(); options.ClrDebuggingEnabled = true; _pe = new PythonEngine(options); _pe.ExecuteFile(@ script ); Test script: x = 1 y = 2 def Add(a, b): return a + b z = Add(x, y) print z I opened the script file in Visual Studio and placed a breakpoint at the beginning of the file. The application runs and breaks at the correct location. Stepping through the lines works, but I cannot see any values of the global variables. When I try to step into the function I get a notification that there is no source code available and I must show the disassembly. After I step several times through the assembly instructions I can return to the original source code. Inside the function I can see the values of the function variables. I have tried debugging ipy.exe with the script and there I can see the global variables, but I still have the problem with stepping into a function. In ipy.exe the script file is executed in a different way. Using the same method I can also see the global variables with my PythonEngine instance. I apparently dont need to set ClrDebuggingEnabled in this case. PythonEngine _pe; _pe = new PythonEngine(); OptimizedEngineModule engineModule = _pe.CreateOptimizedModule(@ script , __main__, true); engineModule.Execute(); Are you required to use an OptimizedEngineModule to be able to debug completely? Am I forgetting some settings for debugging? Can I step directly into a function without getting into the assembly instructions
Re: [IronPython] Embedding Question
Another alternative is: ClrModule clr = (ClrModule)engine.Import(clr); clr.AddReference(typeof(SomeAutoCadType).Assembly); This is similar to doing engine.LoadAssembly(typeof(SomeAutoCadType).Assembly), but is more robust since it also updates clr.References. PythonEngine.LoadAssembly should be deprecated in favor of ClrModule.AddReference. Shri Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Slide Sent: Thursday, August 10, 2006 3:02 PM To: Discussion of IronPython Subject: Re: [IronPython] Embedding Question There is also an Import method on the PythonEngine object that allows you to import stuff programatically as well. On 8/10/06, Kristof Wagemans [EMAIL PROTECTED] wrote: Isn't engine.LoadAssembly(typeof(SomeAutoCadType).Assembly) easier or is this different in some way? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Thursday 10 August 2006 21:17 To: Discussion of IronPython Subject: Re: [IronPython] Embedding Question Cool, looks like I was only close though J You may have already imported clr into the default module, but just for the record for those who haven't you'll need an import clr there. I just realized I forgot it the 1st time, and I had a redundant AddReference in the delegate call. I'm assuming you just fixed all that up, but just in case anyone else needs to do something like this, here's the correct code: delegate void AddReference(object assembly); AddReference adr = engine.CreateMethodAddReference(import clr\nclr.AddReference(assembly)); adr(typeof(SomeAutoCadType).Assembly); ___ 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 ___ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] IP v8 Hosting question...
You would need to do the following. engine.Sys.modules.Remove(myModuleName); Since engine.Sys.modules is a regular Python dict, it is indexed using strings, not SymbolIDs. Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Henderson Sent: Tuesday, June 27, 2006 8:15 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] IP v8 Hosting question... Sweet, I'm naming the modules which probably explains where I'm running into issues... everything I use (that I care about collecting during runtime) are snippets... I don't imagine anything I have needs publishing in sys... incidentally to remove a module from sys, do I just need to do something like engine.Sys.modules.Remove(SymbolTable.StringToId(myModuleName)); ? -Original Message- From: [EMAIL PROTECTED] [mailto:users- [EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Wednesday, 28 June 2006 3:05 p.m. To: Discussion of IronPython Subject: Re: [IronPython] IP v8 Hosting question... We publish the ModuleScope to sys.modules if you do scope = new ModuleScope(some name); We don't publish the ModuleScope if you do scope = new ModuleScope(); Note that we are thinking of changing this to let the user explicitly chose whether the module is published to sys.modules. Code compiled by all the PythonEngine APIs should generate collectible code except for: If you pass in ExecutionOptions.EnableDebugging. If you use ExecuteFileOptimized (formerly known as RunFile) You should not need to worry about memory leaks. I will add a test case to ensure that this stays this way. Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE- 11F0-45DF-8B78-DC1B43134038) -Original Message- From: [EMAIL PROTECTED] [mailto:users- [EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Tuesday, June 27, 2006 6:47 PM To: Discussion of IronPython Subject: Re: [IronPython] IP v8 Hosting question... Two things could be causing the increasing memory usage: 1. Instances of modules hanging around. If you're creating new modules those are getting published in sys.modules, then you'll keep these things around (you could manually remove them from sys.modules and they should be collected after that). 2. Code compiled in a module will not be collectible - it will get compiled into a type in-memory that won't get unloaded until app domain unload. Code compiled stand-alone (e.g. from Python doing exec or eval) will be collectible and go away when the GC kicks in. In general this should come down to RunFile* will not be collectible, and everything else is. We do have a mode, -X:GenerateAsSnippets, which forces everything to be generated in mode #2. But there are significant performance benefits to having the non-collectible code. Everything else should be collectible. From: [EMAIL PROTECTED] On Behalf Of Alex Henderson Sent: Tuesday, June 27, 2006 6:19 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] IP v8 Hosting question... Yeah, I arrived at this yesterday after some experimentation :) I've since dumped the idea of setting global variables (as it's obviously not thread safe for multiple threads evaluating the same expression) and now generate methods for the expression i.e. For an expression: Hello + Message I would end up generating def generated_method_1(Message): return Hello + Message Then execute that against a newly created module, then evaluate generated_method_1, casting it to a PythonFunction and Call that with the array of values that make up my context... works well now and suits my needs perfectly as I can wrap up iron python to work with our standard scripting interfaces. When I no longer need these methods I set their value to None, but I'm wondering if generating methods like this will incur overhead I can't get back (ie. will my apps memory consumption just keep growing, until the python engine itself is shut down?) It certainly seems a little like that when I've been unit testing, but perhaps that's a side effect of the NUnit environment? Chez, - Alex -Original Message- From: [EMAIL PROTECTED] [mailto:users- [EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Wednesday, 28 June 2006 9:55 a.m. To: Discussion of IronPython Subject: Re: [IronPython] IP v8 Hosting question... We will are taking a look at the API and will be changing it a bit. The current way of doing this as follows: PythonEngine engine = new PythonEngine(); SymbolId id = SymbolTable.StringToId(Message); ModuleScope scope1 = new ModuleScope(Junk1); scope1.SetGlobal(id, hello); ModuleScope scope2 = new ModuleScope(Junk2
Re: [IronPython] IP v8 Hosting question...
We publish the ModuleScope to sys.modules if you do scope = new ModuleScope(some name); We don't publish the ModuleScope if you do scope = new ModuleScope(); Note that we are thinking of changing this to let the user explicitly chose whether the module is published to sys.modules. Code compiled by all the PythonEngine APIs should generate collectible code except for: If you pass in ExecutionOptions.EnableDebugging. If you use ExecuteFileOptimized (formerly known as RunFile) You should not need to worry about memory leaks. I will add a test case to ensure that this stays this way. Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Tuesday, June 27, 2006 6:47 PM To: Discussion of IronPython Subject: Re: [IronPython] IP v8 Hosting question... Two things could be causing the increasing memory usage: 1. Instances of modules hanging around. If you're creating new modules those are getting published in sys.modules, then you'll keep these things around (you could manually remove them from sys.modules and they should be collected after that). 2. Code compiled in a module will not be collectible - it will get compiled into a type in-memory that won't get unloaded until app domain unload. Code compiled stand-alone (e.g. from Python doing exec or eval) will be collectible and go away when the GC kicks in. In general this should come down to RunFile* will not be collectible, and everything else is. We do have a mode, -X:GenerateAsSnippets, which forces everything to be generated in mode #2. But there are significant performance benefits to having the non-collectible code. Everything else should be collectible. From: [EMAIL PROTECTED] On Behalf Of Alex Henderson Sent: Tuesday, June 27, 2006 6:19 PM To: 'Discussion of IronPython' Subject: Re: [IronPython] IP v8 Hosting question... Yeah, I arrived at this yesterday after some experimentation :) I've since dumped the idea of setting global variables (as it's obviously not thread safe for multiple threads evaluating the same expression) and now generate methods for the expression i.e. For an expression: Hello + Message I would end up generating def generated_method_1(Message): return Hello + Message Then execute that against a newly created module, then evaluate generated_method_1, casting it to a PythonFunction and Call that with the array of values that make up my context... works well now and suits my needs perfectly as I can wrap up iron python to work with our standard scripting interfaces. When I no longer need these methods I set their value to None, but I'm wondering if generating methods like this will incur overhead I can't get back (ie. will my apps memory consumption just keep growing, until the python engine itself is shut down?) It certainly seems a little like that when I've been unit testing, but perhaps that's a side effect of the NUnit environment? Chez, - Alex -Original Message- From: [EMAIL PROTECTED] [mailto:users- [EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Wednesday, 28 June 2006 9:55 a.m. To: Discussion of IronPython Subject: Re: [IronPython] IP v8 Hosting question... We will are taking a look at the API and will be changing it a bit. The current way of doing this as follows: PythonEngine engine = new PythonEngine(); SymbolId id = SymbolTable.StringToId(Message); ModuleScope scope1 = new ModuleScope(Junk1); scope1.SetGlobal(id, hello); ModuleScope scope2 = new ModuleScope(Junk2); scope2.SetGlobal(id, goodbye); Assert.AreEqual(hello, engine.Evaluatestring(Message, scope1, ExecutionOptions.Default)); Assert.AreEqual(goodbye, engine.Evaluatestring(Message, scope2, ExecutionOptions.Default)); Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE- 11F0-45DF-8B78-DC1B43134038) -Original Message- From: [EMAIL PROTECTED] [mailto:users- [EMAIL PROTECTED] On Behalf Of Alex Henderson Sent: Monday, June 26, 2006 5:03 PM To: 'Discussion of IronPython' Subject: [IronPython] IP v8 Hosting question... I'm looking for the most appropriate way to scope variables for my expression to evaluate that come from an external context (ie. Outside of the python engine) - So far I have something working, using ModuleScope - but is this the way I should be doing it? PythonEngine engine = new PythonEngine(); SymbolId id = SymbolTable.StringToId(Message); ModuleScope scope1 = ModuleScope.MakeScopeForFunction(new PythonModule(Junk, new Dict(), engine.Sys)); scope1.SetGlobal(id, hello); ModuleScope scope2 = ModuleScope.MakeScopeForFunction(new PythonModule(Junk, new Dict(), engine.Sys)); scope2.SetGlobal(id, goodbye
Re: [IronPython] IronPython and LINQ
Hi Kevin, IronPython 1.0 will not support LINQ. We have started to look at it, but will seriously look at it after the summer. It is a meaty issue given that many of the concepts in LINQ are based on static typing. Here is the LINQ information for those who haven't seen it yet - http://msdn.microsoft.com/data/ref/linq/. Thanks Shri Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Chu Sent: Wednesday, May 10, 2006 7:24 PM To: Discussion of IronPython Subject: [IronPython] IronPython and LINQ LINQ Preview May 2006 released! Can IronPython use LINQ? -- Once in a Redmoon ___ 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
