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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]<mailto:[EMAIL
PROTECTED]>> 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: [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]> [mailto:[EMAIL
PROTECTED]<mailto:[EMAIL PROTECTED]>] 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
> <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> 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
> [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
> _______________________________________________
> Users mailing list
> [email protected]<mailto:[email protected]>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
_______________________________________________
Users mailing list
[email protected]<mailto:[email protected]>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
[email protected]<mailto:[email protected]>
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
