What is the type of children and how does it check the len? Maybe there's something wrong or broken on our side which is leading us down to this code path. It could also be that the exception shouldn't occur but there's something wrong in the Python code that causes us to get to the exception (and would presumably do the same on CPython).
Otherwise if the exception occurs on both CPython and IP then I think the IndexOutOfRangeException is correct. VS does have a "Just My Code" feature so depending on if you're trying to debug IP or a mix of Python code and your own C# code you might find your experience to be better if you don't build IP. Instead just debug your Python code & C# code against the released binaries (or your own build w/o PDBs). Without the PDBs for the IP code VS should then only recognize the Python code and your C# and only show you the exceptions coming from your code. Obviously if you're hacking on the IP runtime this doesn't help you :). -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cesar Koers Sent: Tuesday, March 13, 2007 1:07 PM To: Discussion of IronPython Subject: Re: [IronPython] Using python docutils from C# - difference between shell and embedded engine? Thanks for pointing me in the right direction. Although unchecking everything in the Debug->Exceptions "thrown" column does not change the described behaviour. The stacktrace showed that the particular python exception thrown inherited from System.IndexOutOfRangeException. Unchecking "User-unhandled" for that exception does the trick. I am not sure if this is desired behaviour, as I believe that the same exception could easily be raised in C# code - not causing the debugger to break with these settings. Running in Release mode goes fine (the fact that it hung before was probably due to interference with NUnit). Dino Viehland wrote: > Could it be that you have 1st chance exceptions enabled and this exception is > actually handled and recovered from? Python programs tend to throw > exceptions more than your typical C# app. Given that stepping out seems to > allow the program to complete this sounds like what's happening. > > You can disable 1st chance exceptions w/ Debug->Exceptions and then uncheck > anything checked in the "Thrown" column. Leave "User Unhandled" checked. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cesar Koers > Sent: Tuesday, March 13, 2007 3:13 AM > To: users@lists.ironpython.com > Subject: [IronPython] Using python docutils from C# - difference between > shell and embedded engine? > > Hi all, > > I could use some help with embedding Python docutils > (http://docutils.sourceforge.net/) with C#. At this point, I'm able to > use the 'docutils.core.publish_string' function from the ipy.exe shell > with decent output. > > However, when embedding the PythonEngine in my C# app, and executing > 'docutils.core.publish_string' with the exact same arguments (*), > execution stops at a "raise TypeError" in Python code (in Debug mode, in > Release mode I believe it doesn't return from the Python code at all). > Repeatedly stepping out of the Python code (10-15 times) with the > debugger finishes the program. > > VS shows that the TypeError is caused by indexing a null array (named > 'children'). When examining the call stack though, I understood that the > program shouldn't even reach this code because it first checks the value > of 'len(children)' before accessing 'children'. > > > Could there be a problem with environment settings or something? I > compared path and loaded modules between ipy.exe session and embedded > engine; there are some differences which i can't explain. > > > Best regards, > > C > > (*) note that importing docutils.core requires executing > PythonEngine.InitializeModules first and > PythonEngine.Import("docutils.core") is not a substitute for > PythonEngine.Execute("import docutils.core") > > > > PS: using "IronPython Community Edition r5" and VS Express 2005 > _______________________________________________ > 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 > > _______________________________________________ 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
