[IronPython] HybridMapping is full Error
Hello, After upgrading to IronPython 1.1.1 we are seeing (sporadically) the following exception when we run our full test suite. Any idea what the cause(s) could be? Unexpected SystemException running tests: System.SystemException: HybridMapping is full at IronPython.Runtime.HybridMapping`1.WeakAdd(T value) at IronPython.Runtime.PythonFile..ctor(Stream stream, Encoding encoding, String mode, Boolean weakMapping) at IronPython.Runtime.PythonFile.Make(ICallerContext context, DynamicType cls, String name, String mode, Int32 bufsize) at IronPython.Runtime.PythonFile.Make(ICallerContext context, DynamicType cls, String name, String mode) at Make##3549(ICallerContext , Object , Object , Object ) at IronPython.Runtime.Calls.FastCallableWithContext3.Call(ICallerContext context, Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.FastCallableWithContext3.Call(ICallerContext context, Object[] args) at IronPython.Compiler.MethodBinder.MethodTarget.Call(ICallerContext context, Object[] args) at IronPython.Compiler.MethodBinder.TargetSet.Call(ICallerContext context, CallType callType, Object[] args) at IronPython.Compiler.MethodBinder.TargetSet.Call3(ICallerContext context, Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.FastCallableWithContextAny.Call(ICallerContext context, Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.FastCallableWithContextAny.Call(ICallerContext context, Object[] args) at IronPython.Runtime.Calls.BuiltinFunction.Call(ICallerContext context, Object[] args) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object[] args) at IronPython.Runtime.Types.DynamicType.CreateInstance(ICallerContext con text, Object[] args, String[] names) at IronPython.Runtime.Types.DynamicType.Call(ICallerContext context, Obje ct[] args, String[] names) at IronPython.Runtime.Types.DynamicType.Call(ICallerContext context, Obje ct[] args) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object[] args) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0, Object arg1) at linecache.updatecache$f105(Object filename) in C:\Dev\buildshare\Resol ver-df367\python24\linecache.py:line 105 at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0) at linecache.getlines$f103(Object filename) in C:\Dev\buildshare\Resolver -df367\python24\linecache.py:line 40 at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0) at linecache.getline$f101(Object filename, Object lineno) in C:\Dev\build share\Resolver-df367\python24\linecache.py:line 14 at IronPython.Runtime.Calls.Function2.Call(ICallerContext context, Object arg0, Object arg1) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0, Object arg1) at traceback.extract_tb$f89(Object tb, Object limit) in C:\Dev\buildshare \Resolver-df367\python24\traceback.py:line 101 at IronPython.Runtime.Calls.Function2.Call(ICallerContext context, Object arg0, Object arg1) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0, Object arg1) at traceback.format_tb$f88(Object tb, Object limit) in C:\Dev\buildshare\ Resolver-df367\python24\traceback.py:line 76 at IronPython.Runtime.Calls.Function2.Call(ICallerContext context, Object arg0, Object arg1) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0, Object arg1) at traceback.format_exception$f91(Object etype, Object value, Object tb, Object limit) in C:\Dev\buildshare\Resolver-df367\python24\traceback.py:line 142 at IronPython.Runtime.Calls.Function4.Call(ICallerContext context, Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0, Object arg1, Object arg2) at unittest._exc_info_to_string$f13(FunctionEnvironment16Dictionary $env, Object self, Object err, Object test) in C:\Dev\buildshare\Resolver-df367\pytho n24\unittest.py:line 153 at IronPython.Runtime.Calls.Function3.Call(ICallerContext context, Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.PythonFunction.CallInstance(ICallerContext co ntext, Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.Method.Call(ICallerContext
Re: [IronPython] Exporting Python code as an assembly
I've created a project on CodePlex now. It's still in setup mode; send me email and I'll add you to the project there. The only real change I've made since the Feb 5 version are support for static and class methods. And if the class defines a static or class method named Main, I set that as the entry point. On Feb 5, 2008 12:00 PM, Curt Hagenlocher [EMAIL PROTECTED] wrote: You can download my work-in-progress from http://hagenlocher.org/software/ClrWrapper.zip The source consists of the three files ClrBuilder.py, ClrWrapper.py and MakeModule.py. There are also two demo files: Xtest.py and WcfServer.py. The program can currently be run as follows: PS F:\IronPython-2.0A8 *.\ipy.exe MakeModule.py Xtest.py* This will produce a file called Xtest.dll. At this point, the application doesn't require any of the standard Python library files. It's only been tried with the Alpha 8 binaries -- and in fact, the hosting interfaces for IronPython still aren't entirely stable so there's no guarantee that the DLLs produced will work with Alpha 9. Xtest.py is a trivial application that implements a single xunit-compatible unit test PS F:\IronPython-2.0A8 *.\xunit.console.exe Xtest.dll /noshadow* . Total tests: 1, Failures: 0, Skipped: 0, Time: 0.275 seconds WcfServer.py theoretically implements a WCF server, though I haven't gotten as far as actually testing the output yet. (The generated code passes the eyeball compiler.) Code quality is unimpressive; your mileage may vary. And I've got to get back to my day job for a few hours now :). -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Exporting Python code as an assembly
Dino,
Thanks for the insight. That helpls a lot. Too bad that we still won't
be able to create IP types with the DLR in 2.0. I was hoping that that
would be a feature.
By the way, do you guys have an idea of when 2.0 final will be released?
Or at least an idea of what stages it has left to go through (how many
more alpha stages, beta releases, RC's)? I couldn't find this on
CodePlex.
Thanks,
Rocco
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Wednesday, February 06, 2008 3:54 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
The extra __'s are expected. When we enabled this in 1.1.1 we didn't
want to significantly alter the experience between 1.1 and 1.1.1. The
problem with 1.1 was that if the caller passed in an attribute to filter
by (DataGridView passes in BrowsableAttribute) we would say attributes?
We don't have attributes, so you'll get an empty collection. In 1.1.1
we'll return just about anything if browsable is set. In 2.0, where we
have a little more leeway to change things, we're more aggressive about
filtering out things you probably don't want to see. You can always not
auto-generate the columns and you'll get the columns you presumably
want.
The AllowNew is going to be an unfortunate limitation - Python type
instances can't (easily) be created by anyone except for the Python
runtime. The reason is we need to pass a PythonType object into the
contructor so the object knows it's type in the Python world. So we
probably can't do much about this one L.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Wednesday, February 06, 2008 12:47 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
Dino,
Ah ha! Well, it didn't work under 1.1, but under 1.1.1, it worked
nearly right out of the box. When I used a static interface under 1.1,
I only got the static properties in the DataGridView. However, under
1.1.1, I am getting a whole extra slew of information in my Grids
(__weakref__, __doc__, the hidden values, the properties themselves,
every function in the type) when I turn on AutoColumnGenerate. Is this
what I should be expecting?
Also, it seems that if I turn on user creation of new elements
(BindingList.AllowNew = True), then the component crashes with an error
stating that it cannot find the constructor for my type, whether or not
I have defined it. Is this also to be expected or not?
Thank you,
Rocco Pigneri
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Tuesday, February 05, 2008 4:55 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
Data binding isn't working for you? We have support for this via
CustomTypeDescriptors which describe the Python objects and we have some
test cases to verify it works. Note it was broken before 1.1.1 although
it's been working in 2.0 for a little while now. For example:
import clr
clr.AddReference('System.Windows.Forms')
import System.Windows.Forms as SWF
import System
class AgeQualifier(object):
def __get__(self, instance, ctx):
if instance.Age 13: return 'young'
if instance.Age 20: return 'teen'
if instance.Age 30: return 'twenties'
if instance.Age 40: return 'thirties'
if instance.Age 50: return 'forties'
return 'old'
SAMPLE_DATA = [('Joe', 23, 'twenties'), ('Bob', 8, 'young'),
('Thomas', 32, 'thirties'), ('Patrick', 41, 'forties'), ('Kathy', 19,
'teen'), ('Sue' , 77, 'old'),]
class Person(System.Object):
def __init__(self, name, age):
self._name = name
self._age = age
def get_name(self):
return self._name
def set_name(self, value):
self._name = value
Name = property(get_name, set_name)
def get_age(self):
return self._age
def set_age(self, value):
self._age = value
Age = property(get_age, set_age)
AgeDescription = AgeQualifier()
class Form(SWF.Form):
def __init__(self):
SWF.Form.__init__(self)
self._people = people = []
for name, age, ignored in SAMPLE_DATA:
people.append(Person(name, age))
grid = SWF.DataGridView()
grid.AutoGenerateColumns = True
grid.DataSource = people
grid.Dock = SWF.DockStyle.Fill
self.grid = grid
self.Controls.Add(grid)
form = Form()
SWF.Application.Run(form)
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Tuesday, February 05, 2008 9:15 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
Curt,
This is a great feature and was one of the first features that I
investigated when I first got my hands on IP.
I
Re: [IronPython] Decorators on classes
Dino Viehland wrote: This might be something fun to look at during the sprints at PyCon. I will definitely be staying for the sprints - either as part of a Resolver sprint or under my own steam... Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, February 04, 2008 2:55 PM To: Discussion of IronPython Subject: Re: [IronPython] Decorators on classes Hello Dino, That sounds *great*, and is something really needed by IronPython. How long do you think it will take you to implement? 0.5 wink Michael http://www.manning.com/foord Dino Viehland wrote: Ok, maybe it's a little optimistic or maybe it needs a couple of hooks exposed, but it's not too crazy. As other people have pointed out decorators are a runtime concept and I don't think we get to change that. So consider a class decorator such as: def ClrAttribute(attr): def attrFunc(class): # do something smart here with attr return attrFunc @ClrAttribute(System.SerializableAttribute) class X(ISomething, object): @ClrAttribute(SomeOtherAttribte) def DoSomething(self): return 42 As Curt mentioned we do a bunch of caching and such with NewTypeMaker and maybe spit out a new type. That's all going to happen before the decorator gets to run - but we'll only create a new type once so there isn't too much overhead here :). From there you could copy that type w/ Reflection.Emit but add the attribute(s) on it, and then create a new instance of it passing in the PythonType object to its constructor (that's how Python types work - the instance holds onto a copy of the PythonType, the one problem here being that the UnderlyingSystemType of the PythonType would now be wrong, so that might need a hook). This could also include applying the attributes to methods and potentially manifesting concretely typed methods. This same sort of approach might even work w/ a meta-class. Plugging into NewTypeMaker would simplify this but I don't think makes it impossible. There's also other potential problems with systems based up types and attributes: Sometimes they want a type that lives in an assembly and sometimes they want to create instances of types (and they don't know to pass in a PythonType object to the constructor). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Monday, February 04, 2008 2:03 PM To: Discussion of IronPython Subject: Re: [IronPython] Decorators on classes Dino Viehland wrote: FYI IP 2.0 is tracking 2.5 and we have the big pieces in place plus many small pieces (although there's more to go). In 1.1 we had -X:Python25 which enabled selective 2.5 features and we could conceptually do the same sort of thing for 2.0 so that it includes one or two 2.6 features such as class decorators. From there the decorators to support attributes could even be written in Python. Is that right - could attributes be added to an IronPython class (or instances) at runtime using reflection? Earlier parts of this conversation implied that this wasn't the case... Decorators are only syntactic sugar, so the lack of class decorators isn't an impediment... Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith J. Farmer Sent: Monday, February 04, 2008 1:40 PM To: Discussion of IronPython; Discussion of IronPython Subject: Re: [IronPython] Decorators on classes Grandfathering: Giving more consideration to retaining compatibility than it deserves. :) Obviously, IronPython should prioritize compatibility with Py2.4, but for obvious reasons I limit that to seeing IP as a consumer of CPy, not the other way around. On the other hand, IP must also be able to consume .NET, and .NET is increasingly making use of things the IP cannot yet express. (I thought of another framework that attributes are used on -- WCF. There are also XML serialization attributes.) To that end, I think it would be worthwhile, for the purpose of .NET attributes, to have decorators or their analogues available to IronPython in the current stage of development. That is, I think it should be that IronPython = CPy 2.4 + .NET Attributes + other .NET-isms expressed in a Pythonic way. From: [EMAIL PROTECTED] on behalf of Michael Foord Sent: Mon 2/4/2008 11:53 AM To: Discussion of IronPython Subject: Re: [IronPython] Decorators on classes Keith J. Farmer wrote: I've had no problems with not grandfathering in older APIs, and am quite happy to not grandfather in older syntax, either. What do you mean by 'grandfathering' in this context? Michael I agree that IronPython would have to be able to distinguish between CLR attributes
Re: [IronPython] Exporting Python code as an assembly
We're planning on shipping 2.0 RTM sometime in the 2nd half of this year - but
we don't have a firm date quite yet.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Thursday, February 07, 2008 6:56 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
Dino,
Thanks for the insight. That helpls a lot. Too bad that we still won't be
able to create IP types with the DLR in 2.0. I was hoping that that would be a
feature.
By the way, do you guys have an idea of when 2.0 final will be released? Or at
least an idea of what stages it has left to go through (how many more alpha
stages, beta releases, RC's)? I couldn't find this on CodePlex.
Thanks,
Rocco
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Wednesday, February 06, 2008 3:54 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
The extra __'s are expected. When we enabled this in 1.1.1 we didn't want to
significantly alter the experience between 1.1 and 1.1.1. The problem with 1.1
was that if the caller passed in an attribute to filter by (DataGridView passes
in BrowsableAttribute) we would say attributes? We don't have attributes, so
you'll get an empty collection. In 1.1.1 we'll return just about anything if
browsable is set. In 2.0, where we have a little more leeway to change things,
we're more aggressive about filtering out things you probably don't want to
see. You can always not auto-generate the columns and you'll get the columns
you presumably want.
The AllowNew is going to be an unfortunate limitation - Python type instances
can't (easily) be created by anyone except for the Python runtime. The reason
is we need to pass a PythonType object into the contructor so the object knows
it's type in the Python world. So we probably can't do much about this one :(.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pigneri, Rocco
Sent: Wednesday, February 06, 2008 12:47 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
Dino,
Ah ha! Well, it didn't work under 1.1, but under 1.1.1, it worked nearly right
out of the box. When I used a static interface under 1.1, I only got the
static properties in the DataGridView. However, under 1.1.1, I am getting a
whole extra slew of information in my Grids (__weakref__, __doc__, the hidden
values, the properties themselves, every function in the type) when I turn on
AutoColumnGenerate. Is this what I should be expecting?
Also, it seems that if I turn on user creation of new elements
(BindingList.AllowNew = True), then the component crashes with an error stating
that it cannot find the constructor for my type, whether or not I have defined
it. Is this also to be expected or not?
Thank you,
Rocco Pigneri
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Tuesday, February 05, 2008 4:55 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Exporting Python code as an assembly
Data binding isn't working for you? We have support for this via
CustomTypeDescriptors which describe the Python objects and we have some test
cases to verify it works. Note it was broken before 1.1.1 although it's been
working in 2.0 for a little while now. For example:
import clr
clr.AddReference('System.Windows.Forms')
import System.Windows.Forms as SWF
import System
class AgeQualifier(object):
def __get__(self, instance, ctx):
if instance.Age 13: return 'young'
if instance.Age 20: return 'teen'
if instance.Age 30: return 'twenties'
if instance.Age 40: return 'thirties'
if instance.Age 50: return 'forties'
return 'old'
SAMPLE_DATA = [('Joe', 23, 'twenties'), ('Bob', 8, 'young'), ('Thomas', 32,
'thirties'), ('Patrick', 41, 'forties'), ('Kathy', 19, 'teen'), ('Sue' , 77,
'old'),]
class Person(System.Object):
def __init__(self, name, age):
self._name = name
self._age = age
def get_name(self):
return self._name
def set_name(self, value):
self._name = value
Name = property(get_name, set_name)
def get_age(self):
return self._age
def set_age(self, value):
self._age = value
Age = property(get_age, set_age)
AgeDescription = AgeQualifier()
class Form(SWF.Form):
def __init__(self):
SWF.Form.__init__(self)
self._people = people = []
for name, age, ignored in SAMPLE_DATA:
people.append(Person(name, age))
grid = SWF.DataGridView()
grid.AutoGenerateColumns = True
grid.DataSource = people
grid.Dock = SWF.DockStyle.Fill
self.grid = grid
self.Controls.Add(grid)
form = Form()
SWF.Application.Run(form)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Re: [IronPython] HybridMapping is full Error
It looks like there's an internal limit that prevents us from ever having more than 4096 PythonFile objects in existance. Is it possible that you have that many file objects in existence that aren't getting freed? Also just closing them won't be enough, they actually have to get collected by the GC. I don't think anything has actually changed here between 1.1 and 1.1.1 so it might just be hitting slightly different lifetimes. But this limit does seem pretty stupid (and it's still in 2.0 as well apparently :( ). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Thursday, February 07, 2008 2:58 AM To: Discussion of IronPython Subject: [IronPython] HybridMapping is full Error Hello, After upgrading to IronPython 1.1.1 we are seeing (sporadically) the following exception when we run our full test suite. Any idea what the cause(s) could be? Unexpected SystemException running tests: System.SystemException: HybridMapping is full at IronPython.Runtime.HybridMapping`1.WeakAdd(T value) at IronPython.Runtime.PythonFile..ctor(Stream stream, Encoding encoding, String mode, Boolean weakMapping) at IronPython.Runtime.PythonFile.Make(ICallerContext context, DynamicType cls, String name, String mode, Int32 bufsize) at IronPython.Runtime.PythonFile.Make(ICallerContext context, DynamicType cls, String name, String mode) at Make##3549(ICallerContext , Object , Object , Object ) at IronPython.Runtime.Calls.FastCallableWithContext3.Call(ICallerContext context, Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.FastCallableWithContext3.Call(ICallerContext context, Object[] args) at IronPython.Compiler.MethodBinder.MethodTarget.Call(ICallerContext context, Object[] args) at IronPython.Compiler.MethodBinder.TargetSet.Call(ICallerContext context, CallType callType, Object[] args) at IronPython.Compiler.MethodBinder.TargetSet.Call3(ICallerContext context, Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.FastCallableWithContextAny.Call(ICallerContext context, Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.FastCallableWithContextAny.Call(ICallerContext context, Object[] args) at IronPython.Runtime.Calls.BuiltinFunction.Call(ICallerContext context, Object[] args) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object[] args) at IronPython.Runtime.Types.DynamicType.CreateInstance(ICallerContext con text, Object[] args, String[] names) at IronPython.Runtime.Types.DynamicType.Call(ICallerContext context, Obje ct[] args, String[] names) at IronPython.Runtime.Types.DynamicType.Call(ICallerContext context, Obje ct[] args) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object[] args) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0, Object arg1) at linecache.updatecache$f105(Object filename) in C:\Dev\buildshare\Resol ver-df367\python24\linecache.py:line 105 at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0) at linecache.getlines$f103(Object filename) in C:\Dev\buildshare\Resolver -df367\python24\linecache.py:line 40 at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0) at linecache.getline$f101(Object filename, Object lineno) in C:\Dev\build share\Resolver-df367\python24\linecache.py:line 14 at IronPython.Runtime.Calls.Function2.Call(ICallerContext context, Object arg0, Object arg1) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0, Object arg1) at traceback.extract_tb$f89(Object tb, Object limit) in C:\Dev\buildshare \Resolver-df367\python24\traceback.py:line 101 at IronPython.Runtime.Calls.Function2.Call(ICallerContext context, Object arg0, Object arg1) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0, Object arg1) at traceback.format_tb$f88(Object tb, Object limit) in C:\Dev\buildshare\ Resolver-df367\python24\traceback.py:line 76 at IronPython.Runtime.Calls.Function2.Call(ICallerContext context, Object arg0, Object arg1) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0, Object arg1) at traceback.format_exception$f91(Object etype, Object value, Object tb, Object limit) in C:\Dev\buildshare\Resolver-df367\python24\traceback.py:line 142 at
Re: [IronPython] Exporting Python code as an assembly
Michael, Pigneri, Rocco wrote: Dino, Thanks for the insight. That helpls a lot. Too bad that we still won't be able to create IP types with the DLR in 2.0. I was hoping that that would be a feature. Did you see this article on future CLR/DLR integration? http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx I actually had, and I saw this written in the last paragraph of the Scenarios section: C# developers can currently use reflection to instantiate classes and call arbitrary methods that are not known at compile time. The dynamic extensions to the C# language will make it much easier to make such calls. It sounded like this would allow C# developers to new up an instance of an IPy object, but this contradicts everything that I had heard on this list. So I just assumed that I misread this statement :-). Then when I found out that IPY 1.1.1 supports staticizing properties for data binding, I thought that maybe I was wrong and that it could also support the AllowNew option. I was wrong :-). By the way, do you guys have an idea of when 2.0 final will be released? Or at least an idea of what stages it has left to go through (how many more alpha stages, beta releases, RC's)? I couldn't find this on CodePlex. 'They' did say, not long ago, that IP 2 final would be sometime around the end of this year and *hopefully* coincide with a DLR 1.0 final. You know what, they probably did, and I probably don't remember :-)! I have been learning so much in the last month and a half (IPY, Python itself, IPY Studio, DLR, CLR) that it probably got crowded out by all the other things running through my mind :-). Thank you, Rocco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Thursday, February 07, 2008 10:19 AM To: Discussion of IronPython Subject: Re: [IronPython] Exporting Python code as an assembly Pigneri, Rocco wrote: Dino, Thanks for the insight. That helpls a lot. Too bad that we still won't be able to create IP types with the DLR in 2.0. I was hoping that that would be a feature. Did you see this article on future CLR/DLR integration? http://blogs.msdn.com/charlie/archive/2008/01/25/future-focus.aspx By the way, do you guys have an idea of when 2.0 final will be released? Or at least an idea of what stages it has left to go through (how many more alpha stages, beta releases, RC's)? I couldn't find this on CodePlex. 'They' did say, not long ago, that IP 2 final would be sometime around the end of this year and *hopefully* coincide with a DLR 1.0 final. Michael http://www.manning.com/foord Thanks, Rocco -- -- *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Dino Viehland *Sent:* Wednesday, February 06, 2008 3:54 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Exporting Python code as an assembly The extra __'s are expected. When we enabled this in 1.1.1 we didn't want to significantly alter the experience between 1.1 and 1.1.1. The problem with 1.1 was that if the caller passed in an attribute to filter by (DataGridView passes in BrowsableAttribute) we would say attributes? We don't have attributes, so you'll get an empty collection. In 1.1.1 we'll return just about anything if browsable is set. In 2.0, where we have a little more leeway to change things, we're more aggressive about filtering out things you probably don't want to see. You can always not auto-generate the columns and you'll get the columns you presumably want. The AllowNew is going to be an unfortunate limitation - Python type instances can't (easily) be created by anyone except for the Python runtime. The reason is we need to pass a PythonType object into the contructor so the object knows it's type in the Python world. So we probably can't do much about this one L. *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Pigneri, Rocco *Sent:* Wednesday, February 06, 2008 12:47 PM *To:* Discussion of IronPython *Subject:* Re: [IronPython] Exporting Python code as an assembly Dino, Ah ha! Well, it didn't work under 1.1, but under 1.1.1, it worked nearly right out of the box. When I used a static interface under 1.1, I only got the static properties in the DataGridView. However, under 1.1.1, I am getting a whole extra slew of information in my Grids (__weakref__, __doc__, the hidden values, the properties themselves, every function in the type) when I turn on AutoColumnGenerate. Is this what I should be expecting? Also, it seems that if I turn on user creation of new elements (BindingList.AllowNew = True), then the component crashes with an error stating that it cannot find the constructor for my type, whether or not I have defined it. Is this also to be expected or not? Thank you, Rocco Pigneri
Re: [IronPython] HybridMapping is full Error
Dino Viehland wrote: It looks like there's an internal limit that prevents us from ever having more than 4096 PythonFile objects in existance. Is it possible that you have that many file objects in existence that aren't getting freed? Also just closing them won't be enough, they actually have to get collected by the GC. I don't think anything has actually changed here between 1.1 and 1.1.1 so it might just be hitting slightly different lifetimes. But this limit does seem pretty stupid (and it's still in 2.0 as well apparently :( ). Ok - but although 4096 sounds like a low *general* limit it should be fine for us. We certainly always close our file handles - I wonder why they wouldn't be garbage collected? Hmmm One of our devs did a great blog entry recently on tracing resource leaks in IronPython applications: http://blog.kamil.dworakowski.name/2008/02/debugging-memory-problems-in-ironpython.html Michael Foord Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Thursday, February 07, 2008 2:58 AM To: Discussion of IronPython Subject: [IronPython] HybridMapping is full Error Hello, After upgrading to IronPython 1.1.1 we are seeing (sporadically) the following exception when we run our full test suite. Any idea what the cause(s) could be? Unexpected SystemException running tests: System.SystemException: HybridMapping is full at IronPython.Runtime.HybridMapping`1.WeakAdd(T value) at IronPython.Runtime.PythonFile..ctor(Stream stream, Encoding encoding, String mode, Boolean weakMapping) at IronPython.Runtime.PythonFile.Make(ICallerContext context, DynamicType cls, String name, String mode, Int32 bufsize) at IronPython.Runtime.PythonFile.Make(ICallerContext context, DynamicType cls, String name, String mode) at Make##3549(ICallerContext , Object , Object , Object ) at IronPython.Runtime.Calls.FastCallableWithContext3.Call(ICallerContext context, Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.FastCallableWithContext3.Call(ICallerContext context, Object[] args) at IronPython.Compiler.MethodBinder.MethodTarget.Call(ICallerContext context, Object[] args) at IronPython.Compiler.MethodBinder.TargetSet.Call(ICallerContext context, CallType callType, Object[] args) at IronPython.Compiler.MethodBinder.TargetSet.Call3(ICallerContext context, Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.FastCallableWithContextAny.Call(ICallerContext context, Object arg0, Object arg1, Object arg2) at IronPython.Runtime.Calls.FastCallableWithContextAny.Call(ICallerContext context, Object[] args) at IronPython.Runtime.Calls.BuiltinFunction.Call(ICallerContext context, Object[] args) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object[] args) at IronPython.Runtime.Types.DynamicType.CreateInstance(ICallerContext con text, Object[] args, String[] names) at IronPython.Runtime.Types.DynamicType.Call(ICallerContext context, Obje ct[] args, String[] names) at IronPython.Runtime.Types.DynamicType.Call(ICallerContext context, Obje ct[] args) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object[] args) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0, Object arg1) at linecache.updatecache$f105(Object filename) in C:\Dev\buildshare\Resol ver-df367\python24\linecache.py:line 105 at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0) at linecache.getlines$f103(Object filename) in C:\Dev\buildshare\Resolver -df367\python24\linecache.py:line 40 at IronPython.Runtime.Calls.Function1.Call(ICallerContext context, Object arg0) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0) at linecache.getline$f101(Object filename, Object lineno) in C:\Dev\build share\Resolver-df367\python24\linecache.py:line 14 at IronPython.Runtime.Calls.Function2.Call(ICallerContext context, Object arg0, Object arg1) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0, Object arg1) at traceback.extract_tb$f89(Object tb, Object limit) in C:\Dev\buildshare \Resolver-df367\python24\traceback.py:line 101 at IronPython.Runtime.Calls.Function2.Call(ICallerContext context, Object arg0, Object arg1) at IronPython.Runtime.Operations.Ops.CallWithContext(ICallerContext conte xt, Object func, Object arg0, Object arg1) at
