Hi,
The 2.0beta is not stable enough for me to work with yet.
But 1.1 is leaking memory and not applicable for long running server
application.
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=14454
Wonder how hard to fix #14454 in 1.1 ?
Sakesun Roykiattisak wrote:
Hi,
The 2.0beta is not stable enough for me to work with yet.
But 1.1 is leaking memory and not applicable for long running server
application.
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=14454
Wonder how hard to fix #14454 in 1.1 ?
Note
Note that you can 'fix' this yourself by unsubscribing from events
when
you have finished with them.
I've spend my whold today doing what you've mentioned without any
success yet.
The framework I based on depends heavily on a really complicate
event sequences
that I can hardly
It shouldn't cause the lambda's to be lost. The picture ends up looking like:
+---+ +---+
| Object W/ | | |
| Event ---+- strong ref | Lambda|
+---+ +---+
Great! Thanks Dino.
Michael
Dino Viehland wrote:
It shouldn't cause the lambda's to be lost. The picture ends up looking like:
+---+ +---+
| Object W/ | | |
| Event ---+- strong ref | Lambda|
+---+
If you’re really stuck you could port the beta 2 event handling code back to
1.x and run against your own private build - at least until we do 1.1.2 – I’m
not yet sure when we’ll do that but I’ll make sure we discuss it this week.
It’s not super straight forward, because we now hook each
I really want to see sys.excepthook in IronPython.
The way I see it there's two problems.
1) You cannot assign to the sys module. So we need a fix or workaround
for that. This is the hard part.
2) We also need to intercept exceptions before they leave IPY and
route them to sys.excepthook, which
Thanks for reporting this Michael! We actually discovered this internally
about a year ago in one of the 2.0 Alphas, and made a few changes to get it
(mostly) working again:
E:\Merlin\Main\Languages\IronPython\Samples\IPPowerShellipyd
IronPython 2.0 Beta (2.0.0.1000) on .NET
Dave Fugate wrote:
Thanks for reporting this Michael! We actually discovered this internally
about a year ago in one of the 2.0 Alphas, and made a few changes to get it
(mostly) working again:
E:\Merlin\Main\Languages\IronPython\Samples\IPPowerShellipyd
IronPython 2.0 Beta
#1 shouldn't be a problem - is this only in the Silverlight builds? Certainly
the current desktop IronPython builds allow assignment to sys (both overwriting
existing members as well as creating new members). But I'd expect that to have
worked more or less forever.
For #2 I believe what we
On Tue, Apr 22, 2008 at 4:13 PM, Dino Viehland
[EMAIL PROTECTED] wrote:
#1 shouldn't be a problem - is this only in the Silverlight builds?
Certainly the current desktop IronPython builds allow assignment to sys (both
overwriting existing members as well as creating new members). But I'd
I could be mistaken, but I think it was actually a bug that we did in fact
allow calling update on new-style class dictionaries in 1.0:
IronPython 1.0.60816 on .NET 2.0.50727.1434
Copyright (c) Microsoft Corporation. All rights reserved.
class K(object): pass
...
Dave Fugate wrote:
I could be mistaken, but I think it was actually a bug that we did in fact
allow calling update on new-style class dictionaries in 1.0:
Ah - it is updating on the class rather than the instance - my
mistake... (should be allowed IMHO - but that isn't your fault :-)
13 matches
Mail list logo
