Support for sys._current_frames

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Support for sys._current_frames

Fabio Zadrozny-2
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for sys._current_frames

Stefan Richthofer
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" <[hidden email]>
An: "Jython Developers" <[hidden email]>
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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for sys._current_frames

Jeff Allen-2
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" <[hidden email]>
> *An:* "Jython Developers" <[hidden email]>
> *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 [hidden email]
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for sys._current_frames

Stefan Richthofer
> 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" <[hidden email]>
> An: [hidden email]
> 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" <[hidden email]>
> > *An:* "Jython Developers" <[hidden email]>
> > *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 [hidden email]
> > 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
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for sys._current_frames

Fabio Zadrozny-2
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 <[hidden email]> 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" <[hidden email]>
> An: [hidden email]
> 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" <[hidden email]>
> > *An:* "Jython Developers" <[hidden email]>
> > *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 [hidden email]
> > 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
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Support for sys._current_frames

Stefan Richthofer
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" <[hidden email]>
An: "Stefan Richthofer" <[hidden email]>
Cc: "Jython Developers" <[hidden email]>
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 <[hidden email]> 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" <[hidden email]>
> An: [hidden email]
> 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" <[hidden email]>
> > *An:* "Jython Developers" <[hidden email]>
> > *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 [hidden email]
> > 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
> > [hidden email]
> > 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
> [hidden email]
> 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
[hidden email]
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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Loading...