Yeah, it was surprising to me too :) But your assumption is correct - it'll be
collected like just any other object.
Also Rauhotz has commented on the bug 20399 that if you move the
CreateRuntime/GetEngine calls into the loop that we still leak memory though :(
That definitely looks like a ba
OK, this is definitely surprising.
Is it correct to assume that by setting the compilation to non-optimized
mode, the compilation result will behave like a normal .Net object in being
subjected to normal GC collection when it's out of scope? Or do I have to
explicitly set GC collection after usage
> Another question: Which tool do you guys say is the best for developing
> IronPython + Silverlight apps? I find it hard in Visual Studio since
> the
> debugger only lets you step through the code but you can't see any
> variable
> values.
I use the debugger, and you can see the variable values .
This would appear to be a bad default value for compiling. You can explicitly
disable compiling the code as optimized and it will be fully collectible:
var runtime = Python.CreateRuntime();
var engine = runtime.GetEngine("py");
var sum = 0.0;
PythonCompilerOptions pco = (PythonCompilerOptions)en
It is certainly more like 50% on trivial functions than 10%. Given that I have
this mostly written I think we can probably get it into 2.1.
-Original Message-
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord
Sent: Thursday,
Are there other exceptions being thrown, potentially somewhere on the stack
below game\models\__init__.py on line 144? Maybe we're calling a built-in
function somewhere that's calling back into your code and is doing something
funky with the exception tracking. Can you run this under VS and ge
