2008/12/16 Curt Hagenlocher c...@hagenlocher.org:
This looks like a problem in quite a few of our csproj files. Could you
open up a bug report on CodePlex for this?
Done.
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=20262
--
Seo Sanghyeon
Also: It seems that even normal properties are slower than methods. This
became apparent when we had property access in tight loops. The weird
thing is that this also happens only when using compiled dlls.
Is there something inherently different with compiled python files?
Perhaps some
Here's the simplest version of the fix, it's just updating one file so
properties get their own call sites.
I'll work on a more involved fix that I'll get into 2.1 soon and probably into
2.0.1 a few days later.
Note this diff is from 2.1 but I've updated the names of things that have
changed
Jeff Slutter wrote:
[I can work around this, but I'm curious if there is a solution]
Due to some crazy requirements, I'm trying to load my assemblies from
memory. I have setup an Assembly Resolver with:
AppDomain.CurrentDomain.AssemblyResolve += new
I snipped a little extra - my code is really:
Dictionarystring, object runtimeOptions = new Dictionarystring,
object();
runtimeOptions[Debug] = true;
m_runtime = IronPython.Hosting.Python.CreateRuntime(runtimeOptions);
m_runtime.LoadAssembly(typeof(String).Assembly); // Add reference to System
This is just a test... there were some issues with the mailing list today, just
verifying that it should be back now.
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
There were no issues with making this change revealed by our tests. The change
is in our 2.1 branch internally so should so up externally really soon. I
suspect we'll discuss backporting it to 2.0.1 at one of our team meetings but
unless we hear about some issues this causes then I personally
