[IronPython] Semi-blocking bug in IP 2B1

[Dino Viehland]

There's actually a bunch of issues tangled together here but you're right, changing that statement would make the frames more usable...  There's actually some thoughts that our dynamic stack trace support should be pulled up entirely into IronPython and that might just happen.

The other issues are just related to how we generally produce frames.  For example if you do:

try:
                raise ZeroDivisionError
except:
                # start extracting frames from sys.exc_info()

In CPython you get a bunch of frames from above the except block and in IronPython you get no frames.  Turns out the inspect module does this and the latest Django in source control relies on that working :).

So to fix that bug requires that we always take a full stack trace when we get the frames.  And that of course kills exception handling perf in a quite significant way (it gets 3x more expensive to throw an exception, and it's already really expensive).   So we should bring this back w/o having the -D flag enabled, and we might also want to change how we track frames in general to do something better and more consistent w/ CPython.  But we can't push that down into the DLR so there's a non-trivial amount of work here.

From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Curt Hagenlocher
Sent: Monday, March 31, 2008 9:20 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Semi-blocking bug in IP 2B1

LambdaCompiler.Statements.cs basically says "if (Options.DebugMode && Options.DynamicStackTraceSupport) EmitGetCurrentLine()".  Maybe this should be "or" instead of "and"?
On Mon, Mar 31, 2008 at 9:13 AM, Dino Viehland <dinov at exchange.microsoft.com<mailto:dinov at exchange.microsoft.com>> wrote:
It's actually something that's on our radar - it feels worse to me too.  It's something I plan on taking a look at before 2.0 final ships.

-----Original Message-----
From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com>] On Behalf Of Michael Foord
Sent: Monday, March 31, 2008 9:04 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Semi-blocking bug in IP 2B1

Curt Hagenlocher wrote:
> On Mon, Mar 31, 2008 at 8:10 AM, Michael Foord
> <michael.foord at resolversystems.com<mailto:michael.foord at resolversystems.com>> wrote:
>
>> In general, error reporting/tracebacks seem to be much worse in
>> IronPython 2. If I have time I will try and produce a repro...
>>
>
> If you run with a -D flag, you get much better error reporting.  This
> is equivalent to setting (ScriptRuntime).GlobalOptions.DebugMode =
> true in a hosting scenario.
>
> (Thanks to Jimmy Schementi's post on the IronRuby list for pointing me at this.)
>

Ok - and thanks. But we generate and execute code at runtime and need
good error reporting for our users. If there is a performance
implication we wouldn't want to have to set this flag just to be able to
give our users useful tracebacks! The IP traceback handling is generally
fine for us - but I haven't *confirmed* that IP 2 is worse - it just
feels worse...

We have bigger problems anyway. Now I have ironed out the obvious
problems, Resolver One runs on IP 2 but the user interface is completely
broken. That is all pure-Python code so I have some digging to do... :-)

Michael



> --
> Curt Hagenlocher
> curt at hagenlocher.org<mailto:curt at hagenlocher.org>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>

_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users at lists.ironpython.com<mailto:Users at lists.ironpython.com>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080331/fdbbb3d9/attachment.html>