|
Sys._getframe() is likely significantly harder to implement. I’d
be a little bit surprised if we get this into 1.1 but it’d be nice to get at
some point in the future. The hard part of this probably isn’t supporting
sys._getframe() but actually supporting sys._getframe(depth). Do you know if the parameterless version will unblock you, or do
you need the full blown functionality? From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jean-Yves MENGANT Complementary : Looking at the 1042 , I saw another unclear topic
around the the sys_getframe entry which is marked as not supported already
throwing a ValueError exception + ‘The sys._getframe() function is not
supported by IronPython‘ is also written in the ‘differences between IronPython and
CPython’ ; I hope that this is only on short term limitation as welll
since this api is also fundamental for Python debugger’s implementation’s Stack
frame analysis and is referenced inside bdb.py standard python module Thanks for your answer below Jean-Yves From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dino Viehland We have a couple of bugs opened on this on CodePlex for this
issue: 563: Support
for Code Quality Tools in IronPython missing 1042: Implement
various sys module methods that currently throw a NotImplementedException We believe we know how to implement sys.settrace (we’d hook
it at the same place we hook our recursion checks today) but we haven’t had
time to get to it yet. Currently this is scheduled in our bug database as
1.1 feature (although that may be subject to change) but it’s good to note that
we are seeing additional demand for these APIs. This will help us
prioritize our 1.1 work better. Hopefully we’ll be able to get this in
for 1.1 so it’ll be just a short term limitation. Thanks for the input! From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Jean-Yves MENGANT I
have been playing around with python debugging implementation for a while ,
allthough IronPython is a great effort on Python implementation , lacking
support for some cross platform standard libraries leeds to to serious
limitation in ironpython usage versus Cpython on short and long term. One
of the big missing is definitively the the sys.settrace standard function used
inside bdb.py and so inherited by python debugging tools on the planet as a
python standard debugging API entry point for years. The
consequence to this is that trying to support IronPython in a python portable
debugging environment will fail(see below) …. And the only reminding platform
to make debugging happen will be the Visual Studio environment …. Even the
standard pdb.py which inherits bdb.py would not be usable on short term then. Providing
a descent implementation of those low level sys.function as it is already
available within JPython port would definitively provide more support of
IronPython by existing python debugger’s on the planet. Of
xourse sys.settrace is part of the current sys implementation but when it comes
to get executed it’s disappointing : localDebuggee=
None JPyDbg
connecting localhost on port 29111 JPyDbgI0001
: connected to localhost ['Traceback
(most recent call last): ',
' File "F:\\IronPython-1.0\\Lib\\bdb.py", line 361, in run
sys.settrace(self.trace_dispatch) ',
'NotImplementedError: sys.settrace is not yet supported by IronPython '] '+++
JPy/sessionended/ deamon
ended The
not yet supported by IronPython is not really an expected serious
implementation … This makes VisualStudio
as the only python Debugger able to support IronPython in future : Question
is this a strategy or just a short term limitation that will be covered soon ? Thanks
for your support to Python language Jean-Yves
|
_______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
