[IronPython] upgrading to ip 2b3 in Resolver One

Dino Viehland dinov at exchange.microsoft.com
Fri Jun 20 20:41:37 CEST 2008

FYI the deprecation warning is definitely overly zealous and that should be fixed for beta 4.  The other issues here do look like bugs and I'll go ahead and start opening them on CodePlex.  The __name__ one is certainly interesting - __doc__ should be trivial to fix.

On perf: I hope that the perf regression here is related to the regression we caught at the end of Beta 3.  The short of this is that our perf lab was down for maintenance for a week and our check-ins all got back logged.  Therefore we didn't catch the perf regression until the last minute.  I think we're back up to date now so hopefully we can avoid that for future releases.  Independent of our perf lab I was curious and ran Richards.py over the weekend and - we were about 10x slower on that due to a different perf regression vs Beta 2.  That one is related to polymorphic call sites.  Anyway, we should be fixing these regressions for the next release.  If it's easy you might want to try running on Beta 2 and see what the perf difference is there.  Otherwise I look forward to hearing your analysis.

If you get stuck or have something you'd like us to take a look at let us know.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Christian Muirhead
Sent: Friday, June 20, 2008 4:57 AM
To: Discussion of IronPython
Subject: [IronPython] upgrading to ip 2b3 in Resolver One

Hi guys -

I mentioned the other day that I was doing some work towards us porting
Resolver One to IP 2b3. I've got it working (mostly), but hit some bumps
along the way that I figured it would be worth mentioning here:

* As I noted before, passing in arguments to the hosted engine was a bit
obscure (although it sounds like the API for this is a work in progress).

* Another thing I saw here was that you can't set __name__ in a scope
when running a script loaded from a source file - that is, this:

ScriptSource source = engine.CreateScriptSourceFromFile("test.py");
ScriptScope scope = e.CreateScope();
scope.SetVariable("__name__", "__main__");

when test.py contains

print __name__

prints "test"

* Can't assign to an instance's __doc__ attribute - we use this for our
documentation generation in one place. (This works in IP 1.1.1, and
CPython.) Shouldn't be hard to work around in the meantime.

* We get deprecation warnings when we access protected members of C#
classes from IP subclasses - I can understand this for code outside of
subclasses (which shouldn't work but does in IP 1.1.1), but it would be
nice if it still worked from code in a subclass. (This would be easy to
work around for us - the protected members are all on dialogs we define
in C#, so we can change them to public if we need to.)

D'oh - I was just about to tell you about a weird thing I had seen where
calling ScriptScope.SetVariable(name, value) when value is None fails -
it dispatches to the (string, ObjectHandle) overload for some reason.
Then I realised that the problem was that I was trying to use the C# API
from IP, when I could just call setattr with the scope instead. That
works fine. (And now I remember the .Overloads property to select
between them.)

Now that it's working, the performance is about 4x slower than under
1.1.1. I'm in the process of drilling down into that for specific
operations that are drastically different - hopefully they'll be nicely


Christian Muirhead
Resolver Systems
christian.muirhead at resolversystems.com
We're hiring! http://www.resolversystems.com/jobs/

Resolver Systems Ltd
17a Clerkenwell Road, London EC1M 5RD, UK
VAT No.: GB 893 5643 79 Registered in England and Wales as company
number 5467329.
Registered address: 843 Finchley Road, London NW11 8NA, UK
Users mailing list
Users at lists.ironpython.com

More information about the Ironpython-users mailing list