Re: 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