[IronPython] Roadmap and updates

[Dino Viehland]

FYI one thing that might help on the debugging side is the -X:ExceptionDetail command line option to ipy.exe.  This is particular useful if you're getting something like a NullReferenceException or IndexError's because usually it leads right to the culprit.  In this case that displays this stack trace:

   at IronPython.Runtime.Operations.PythonTypeOps.CallWorker(CodeContext context, PythonType dt, IAttributesCollection kwArgs, Object[] args) in C:\Product\3\Merlin\Main\Languages\IronPython\IronPytho
n\Runtime\Operations\PythonTypeOps.cs:line 97
   at IronPython.Runtime.Types.PythonType.Call(CodeContext context, IAttributesCollection kwArgs, Object[] args) in C:\Product\3\Merlin\Main\Languages\IronPython\IronPython\Runtime\Types\PythonType.cs
:line 272
   at _stub_$37##27(Closure , CallSite , CodeContext , Object , String , Object , Object )
   at _stub_MatchCaller(DynamicSiteTarget`6 , CallSite , Object[] )
   at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\CallSite.cs:line 272
   at System.Scripting.Actions.UpdateDelegates.Update5[T,T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\Up
dateDelegates.Generated.cs:line 55
   at _stub_$36##26(Closure , CallSite , CodeContext , Object , String , Object , Object )
   at _stub_MatchCaller(DynamicSiteTarget`6 , CallSite , Object[] )
   at System.Scripting.Actions.CallSite`1.UpdateAndExecute(Object[] args) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\CallSite.cs:line 272
   at System.Scripting.Actions.UpdateDelegates.Update5[T,T0,T1,T2,T3,T4,TRet](CallSite site, T0 arg0, T1 arg1, T2 arg2, T3 arg3, T4 arg4) in c:\Product\3\ndp\fx\src\Core\Microsoft\Scripting\Actions\Up
dateDelegates.Generated.cs:line 55
   at <module>$20$9.<module>$20(Closure , Scope , LanguageContext ) in <stdin>:line 7
   at Microsoft.Scripting.ScriptCode.InvokeTarget(LambdaExpression code, Scope scope) in C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\ScriptCode.cs:line 88
   at Microsoft.Scripting.Runtime.OptimizedScriptCode.InvokeTarget(LambdaExpression code, Scope scope) in C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\OptimizedScriptCode.cs:line 71
   at Microsoft.Scripting.ScriptCode.Run(Scope scope) in C:\Product\3\Merlin\Main\Runtime\Microsoft.Scripting\Runtime\ScriptCode.cs:line 80
   at IronPython.Hosting.PythonCommandLine.<>c__DisplayClass1.<RunOneInteraction>b__0() in C:\Product\3\Merlin\Main\Languages\IronPython\IronPython\Hosting\PythonCommandLine.cs:line 370
IndexError: Index was outside the bounds of the array.

As you can see the top of the stack is the CallWorker and the problem here is that we're just not putting the arg name in the right index in the array.  So something like that might be obvious enough to fix w/o a repro - or it might be pretty easy for us to come up w/ a repro ourselves when we see the call stack.  If we had instead been throwing the exception from one of the _stub_ methods then we'd definitely need a repro as that's generated code and it's not immediately obvious what is going on.

Anyway, this bug appears to be trivial fixed so it'll be in the next release.  Thanks for the bug report and easy repro!



-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Sylvain Hellegouarch
Sent: Tuesday, August 05, 2008 12:05 AM
To: maxyaffe at comcast.net; Discussion of IronPython
Subject: Re: [IronPython] Roadmap and updates

Hi,


> Note:  I originally wrote this to Harry Pierson directly who asked that I
> post it publically. I hope it doesn't come off as too inflamatory.
>
> Harry - Thanks for the roadmap and the latest update.  It clarifies a
> particular issue that I'm having with deciding whether to adopt Iron
> Python
> and .Net for that matter.  My particular application is a scientific
> instrument control and data analysis package.  It runs on Windows now
> using
> various older MS technologies (dating back to Windows 2.3!).  It will not
> need to run from a web browser, mainly because of the requirements for
> instrument control.  The application is highly scripted using a dynamic
> language of my own devising derived from Smalltalk and remarkably similar
> to
> Python.
>
> I had been looking at Qt 4.x+PyQt+Python 2.5 as an approach to updating my
> technology.  However, I wanted to see what Microsoft had to offer.
> WinForms
> + Python seems to be the best fit for my technology because of the need to
> manipulate data tables and my desire to avoid the web.  Silverlight just
> doesn't offer me any advantage and seems to be directed at pretty pictures
> and sounds.  It also doesn't seem to handle the kinds of user/data
> interaction I need.  XAML also doesn't seem to offer any advantage for my
> code, or if it does, it certainly isn't clear what it might be other than
> a
> YAOUHD (yet another obese, unreadable HTML derivative).  Your roadmap,
> however, seems to deprecate WinForms.  I'm worried that IronPython and
> Microsoft are going to cut WinForms adrift just when I'm about to make a
> major investment in it.  This might be the best approach for Microsoft
> because it seems the "community" is mainly interested in pictures, sounds,
> and the web. But I need something more classical.
>
> I'd appreciate your comments and direction.
>

I will not comment on the state of Silverlight or XAML as I don't use them
but I've been using the PyQt4+Python2.5 combination for some time and it's
been working great. My main concern with IronPython at this stage is its
inability to offer a clear view of its capacity to support pure Python
libraries.

I keep running in shortcomings or bugs [1] that make me nervous about
investing time in IP when using existing pure Python libraries. I do
understand IP is still in beta and bugs are expected at this stage but not
having an up-to-date grid of what is officially implemented, supported,
worked on is rather frustrating.

In other words, if you start from scratch then IP+.NET is a solid choice
but if you already have a large bunch of Python code I would personally be
very careful as you might end up having to spend quite a lot of time in
debugging the reason why your code isn't working as expected, opening
tickets on CodePlex and never hearing about their progress again until
they are potentially fixed.

I do not want to sound like I downplay the IP team work, not at all, but
the lack of visibility is not playing in their favor in my opinion.
Writing code is one thing, giving recurrent feedback is sometimes worth
more ;)

I believe IP is worth the interest but keep in mind the product is still
rather a long way.

- Sylvain

[1] http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=17561

It might not sound like it but that bug was quite hard to track down
because of the rather poor traceback information provided by IP as well as
the fact that the IndexError, though a consequence of the bug, wasn't
immediate to correlate back to the bug itself.




--
Sylvain Hellegouarch
http://www.defuze.org
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com