Re: Support for sys._current_frames

I just added a version of sys._current_frames that skips null-frames. See https://hg.python.org/jython/rev/b051f30c4cd4.

So this will be in Jython 2.7.1. Feel free to test it from current trunk version.

-Stefan

Gesendet: Donnerstag, 30. März 2017 um 20:22 Uhr

Von: "Fabio Zadrozny" <[email protected]>

An: "Stefan Richthofer" <[email protected]>

Cc: "Jython Developers" <[email protected]>

Betreff: Re: [Jython-dev] Support for sys._current_frames

Thank you all for the comments.

Given the sample code, I was able to implement a replacement in PyDev, in pure-Python, while Jython itself provides no sys._current_frames (given that it seems simple to implement, it'd be nice to have this in a Jython release sooner rather than later, as my implementation replacement has to access a private attribute -- which is different from the latest 2.7.0 in the downloads to the current development version -- and it'll probably stop working as Jython itself moves forward.

@Stefan: Regarding having None frames, I think that this shouldn't be allowed (not that I couldn't change PyDev to deal with it, but this is not the behavior CPython gives, so, I think the return should be protected to disallow None values -- there are other uses for sys._current_frames, for instance, on PyVmMonitor I use it to gather stack information, and I bet there are other uses out there which wouldn't protect from receiving a None there).

The pure-python replacement I'm using if sys._current_frames is not found is below (may also be seen at: https://github.com/fabioz/PyDev.Debugger/commit/a4a58179dab9f9fb93559066f0ef22ac59c59e04 ).

Thanks,

Fabio

from java.lang import NoSuchFieldException

from org.python.core import ThreadStateMapping

try:

cachedThreadState = ThreadStateMapping.getDeclaredField('globalThreadStates') # Dev version

except NoSuchFieldException:

cachedThreadState = ThreadStateMapping.getDeclaredField('cachedThreadState') # Release Jython 2.7.0

cachedThreadState.accessible = True

thread_states = cachedThreadState.get(ThreadStateMapping)

def _current_frames():

as_array = thread_states.entrySet().toArray()

ret = {}

for thread_to_state in as_array:

thread = thread_to_state.getKey()

if thread is None:

continue

thread_state = thread_to_state.getValue()

if thread_state is None:

continue

frame = thread_state.frame

if frame is None:

continue

ret[thread.getId()] = frame

return ret

On Wed, Mar 29, 2017 at 6:08 PM, Stefan Richthofer <[email protected] > wrote:

> Your elements array should be twice as long, I think?

Obviously it should ;)

Agreed on all points. I just tested the implementation and observed that

an entry in globalThreadStates yields a null-PyFrame. How should we deal

with that?

a) Is it a bug and we should investigate how it can be null and solve it?

b) set the frame to None in result of _current_frames

c) skip such elements and let _current_frames only return a reduced dict?

@Fabio regarding b), would PyDev be robust against None-values here?

Despite this, the result looks rather much like in CPython.

> Gesendet: Mittwoch, 29. März 2017 um 22:04 Uhr

> Von: "Jeff Allen" <[email protected] >

> An: [email protected]

> Betreff: Re: [Jython-dev] Support for sys._current_frames

>

> This seems to be a faithful equivalent to the CPython implementation.

> That is wrapped in a synchronisation construct, but globalThreadStates

> is of a thread-safe class, I see. However, as the number of threads

> might change between the call to size() and the call to toArray(), I

> think it would be better to let toArray() always allocate the array

> (i.e. give it a zero-length prototype).

>

> Your elements array should be twice as long, I think?

>

> The way we manage ThreadState and interpreters leaves me uneasy, but

> that's not a criticism against this proposal, except for the risk of

> change when the penny finally drops.

>

> Oh, and thanks to Fabio for continuing to support Jython in PyDev.

>

> Jeff Allen

>

> On 29/03/2017 17:30, Stefan Richthofer wrote:

> > I suggest this could be implemented in ThreadStateMapping like this:

> > (on top of that an implementation in PySystemState is straight forward)

> > public static PyObject _current_frames() {

> > @SuppressWarnings("unchecked")

> > Map.Entry<Thread, ThreadState>[] entries = new

> > Map.Entry[globalThreadStates.size()];

> > entries = globalThreadStates.entrySet().toArray(entries);

> > PyObject elements[] = new PyObject[entries.length];

> > int pos = 0;

> > for (Map.Entry<Thread, ThreadState> entry: entries) {

> > elements[pos++] = Py.newInteger(entry.getKey().getId());

> > elements[pos++] = entry.getValue().frame;

> > }

> > return new PyDictionary(elements);

> > }

> > Opinions?

> > -Stefan

> > *Gesendet:* Mittwoch, 29. März 2017 um 17:30 Uhr

> > *Von:* "Fabio Zadrozny" <[email protected] >

> > *An:* "Jython Developers" <[email protected] >

> > *Betreff:* [Jython-dev] Support for sys._current_frames

> > Hi Jython devs,

> > I've just updated the PyDev debugger to drop support for older Python

> > versions and it seems I ended up breaking debugging in the current

> > Jython version because of it...

> > The issue is that PyDev now requires sys._current_frames to be

> > implemented by the interpreter (available since Python 2.5), but it

> > seems this is not available for Jython -- this is needed so that the

> > debugger can be faster (i.e.: it runs with untraced frames until some

> > breakpoint is actually added -- at that point it gets the current

> > frames and sets the tracing in them).

> > So, I'd like to check how feasible it'd be to have this support in Jython.

> > Thanks,

> > Fabio

> > ------------------------------------------------------------------------------

> > Check out the vibrant tech community on one of the world's most

> > engaging tech sites, Slashdot.org!

> > http://sdm.link/slashdot_______________________________________________

> > Jython-dev mailing list [email protected]

> > https://lists.sourceforge.net/lists/listinfo/jython-dev

> >

> >

> > ------------------------------------------------------------------------------

> > Check out the vibrant tech community on one of the world's most

> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> >

> >

> > _______________________________________________

> > Jython-dev mailing list

> > [email protected]

> > https://lists.sourceforge.net/lists/listinfo/jython-dev

>

>

> ------------------------------------------------------------------------------

> Check out the vibrant tech community on one of the world's most

> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> _______________________________________________

> Jython-dev mailing list

> [email protected]

> https://lists.sourceforge.net/lists/listinfo/jython-dev

>

------------------------------------------------------------------------------

Check out the vibrant tech community on one of the world's most

engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________

Jython-dev mailing list

[email protected]

https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ Jython-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev