Dino Viehland wrote:
Thanks for the report. I've opened CodePlex bug #19350 to track this
(http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=19350).
I believe the fix is actually pretty simple and we'll discuss whether we'll
take it for 2.0 final at our Friday team meeting. If you want to try out the
fix either to unblock yourself or just see if there's other issues lurking
behind it you can do this change:
Thanks Dino - that fix certainly fixes the specific issue and means I
have less failing tests in my Worksheet test (and no new ones as far as
I can tell).
Although Resolver One now runs on IronPython 2 I'm still in a position
where there are a stack of failing tests (we have 6000 tests in total
and I'm gradually moving through them working out whether failures are
because we are testing against the old API, failures that indicate bugs
in IronPython, failures due to moving to Python 2.5, or anything else...)
Although aspects of Resolver One on IronPython 2 are just as fast as
they are on IronPython 1 there are still some specific performance
issues. We anticipate that the hardest part of the port will be
identifying and fixing those issues (thankfully we have a bunch of
performance tests to help us). If we find anything specific we will
report it back of course.
We would appreciate this fix being in 2.0 final as it is our goal to do
a new Resolver One release based on it as soon as humanly possible, and
we would prefer not to have to rely on a patched version.
Anyway - thanks for identifying a fix so quickly.
All the best,
Michael
return new MetaObject[] {
arguments[0],
new MetaObject(
Ast.Call(
typeof(PythonOps).GetMethod("MakeTuple"),
Ast.NewArrayInit(typeof(object), tupleArgs)
),
- Restrictions.Empty
+ Restrictions.Combine(arguments)
),
arguments[arguments.Length-1]
};
If you just search for "return new MetaObject[]" in PythonProtocol.Operations.cs
you'll get to the right spot. There's a 2nd spot about 20 lines later for the getter case
which has the same issue & fix.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord
Sent: Wednesday, November 05, 2008 8:03 AM
To: Discussion of IronPython
Subject: [IronPython] IronPython 2: Bug in Indexing (Blocker)
Hello Guys,
Discovered a bug in indexing Python objects in IronPython 2.
The following code:
class X(object):
def __setitem__(self, key, value):
print repr(key)
def f(a, b):
X()[a, b] = object()
f(1, 2)
f('one', 'two')
Produces the following exception:
Traceback (most recent call last):
File "bugtest.py", line 9, in bugtest.py
File "bugtest.py", line 6, in f
TypeError: Specified cast is not valid.
It looks like IronPython has a call site that is now expecting integers
the second time round.
Switching to using explicit tuples for indexing works around the problem:
X()[(a, b)] = object()
However this kind of indexing is an *extremely* common way to use our
spreadsheet API from user code, so we couldn't release with this bug in
place.
(Doing the indexing outside of the function also avoids the problem
interestingly enough.)
All the best,
Michael Foord
--
Michael Foord
Senior Software Engineer, Resolver Systems Ltd.
[EMAIL PROTECTED]
+44 (0) 20 7253 6372
Try out Resolver One! <http://www.resolversystems.com/get-it/>
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@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
--
http://www.ironpythoninaction.com/
_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
