Python
› Jython
›
jython-dev
Unicode user and file names (and v2.7.1)
Locked
12
12
Re: Unicode user and file names (and v2.7.1)
 
|
The numbering scheme for Python versions is quite well known. https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work One ought not to interpret the micro-version as more than bug-fix
numbering. While I don't see a prohibition against skipping micro
numbers I think it never seemed sensible to CPython when fear of
double digits was an issue. So I start out opposed to the idea. However, I recognise that 2.7, because there will never be a 2.8,
has become a bit of a special case, and the micro-version might be
read as a maturity claim. I like the logic of using the provenance
of ~/lib-python/2.7/test. So for "clarity in marketing" I'm not
against a modest vorsprung. I don't think Jython 2.7.1 is our last release in that version of the language. I'm sure we'll do more bug-fixes, and some back-ports from 3. (Like others, I've told myself that after this release, I'll give some time to 3.) ... so now, I find I've agreed with everything Stefan said! To answer Stefan's question, the last mass update of lib-python
was 2013/03/09 (https://hg.python.org/jython/rev/f763cd15ee2b).
I don't believe the CPython change set it cites (README says its a
v3.4), while CPython 2.7.4 was in beta at that date. We've pulled
in specific parts of the CPython library since then to meet
specific needs, but made no mass update. This alone seems a good
reason for a further release. Jeff Allen On 22/05/2017 19:03, Stefan Richthofer
wrote:
------------------------------------------------------------------------------ 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 |
Re: Unicode user and file names (and v2.7.1)
|
|
I am in agreement with Stefan as well. I think making 2.7.x
exceptional in that the numbering could convey the version of CPython since so much extra work went into CPython 2.7.x. I'd be against doing that for 3.x.x. Though we'd want to be honest and if the reality is that it is based on (say) 2.7.6 at time of release, that should be the number until we actually do get up to 2.7.12 (or later). On Mon, May 22, 2017 at 1:15 PM, Jeff Allen <[hidden email]> wrote: > The numbering scheme for Python versions is quite well known. > > https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work > > One ought not to interpret the micro-version as more than bug-fix numbering. > While I don't see a prohibition against skipping micro numbers I think it > never seemed sensible to CPython when fear of double digits was an issue. So > I start out opposed to the idea. > > However, I recognise that 2.7, because there will never be a 2.8, has become > a bit of a special case, and the micro-version might be read as a maturity > claim. I like the logic of using the provenance of ~/lib-python/2.7/test. > So for "clarity in marketing" I'm not against a modest vorsprung. > > I don't think Jython 2.7.1 is our last release in that version of the > language. I'm sure we'll do more bug-fixes, and some back-ports from 3. > (Like others, I've told myself that after this release, I'll give some time > to 3.) > > ... so now, I find I've agreed with everything Stefan said! > > To answer Stefan's question, the last mass update of lib-python was > 2013/03/09 (https://hg.python.org/jython/rev/f763cd15ee2b). I don't believe > the CPython change set it cites (README says its a v3.4), while CPython > 2.7.4 was in beta at that date. We've pulled in specific parts of the > CPython library since then to meet specific needs, but made no mass update. > This alone seems a good reason for a further release. > > Jeff Allen > > On 22/05/2017 19:03, Stefan Richthofer wrote: > > If we move away from 2.7.1 at all, the micro version should match the point > where we updated python-lib last time IMO. I doubt it is 2.7.12. Maybe it's > 2.7.6 or so I suspect (sorry if I should be wrong). Does someone now an > efficient way to look it up? > A different numbering scheme for marketing purposes would be misleading and > might disappoint users even more. > > Also. I don't find Jython 2.7.1 should be the last Jython 2.7 or likewise. > There will continue to be (maybe minor) progress and we should release this > based on time intervals (6months was the plan, wasn't it?). IMO it's not so > important that huge progress happens from version to version. Progress from > 2.7.0 to 2.7.1 is actually far too large. Much more important is that there > is progress at all and that it's displayed to the community by frequent > releases. > > -Stefan > > Gesendet: Montag, 22. Mai 2017 um 19:50 Uhr > Von: "Jim Baker" <[hidden email]> > An: "Alan Kennedy" <[hidden email]> > Cc: "Darjus Loktevic" <[hidden email]>, "Jeff Allen" <[hidden email]>, > "Stefan Richthofer" <[hidden email]>, "Jython Developers" > <[hidden email]> > Betreff: Re: [Jython-dev] Unicode user and file names (and v2.7.1) > Alan, > > That's a great suggestion. 2.7 was specifically chosen to show this > correspondence. In the past, we were not so as focused on compatibility, but > most of the changes — and corresponding delays — in what we have been > planning to call 2.7.1 are because of the continued development on CPython > 2.7, by backporting fixes from successive versions of CPython 3. > > So calling it 2.7.12 helps illustrate this. Any other thoughts on Alan's > proposal? > > - Jim > > On Mon, May 22, 2017 at 11:25 AM, Alan Kennedy <[hidden email]> wrote: >> >> Hi folks, >> >> Great to see a solid 2.7.1 jython, and work begin in earnest on jython 3. >> >> I have only one small suggestion to make: if jython 2.7.1 is going to be >> one of the last 2.7 releases, maybe consider numbering it in a way that >> indicates it is derived from the latest version of cpython 2.7.12. This >> could indicate that it is as up-to-date as it can be, i.e. not derived from >> cpython 2.7.1 and then abandoned. >> >> Perception of abandonment is often a problem for jython: I think it's >> worth an effort to counter this mis-perception. >> >> Regards, >> >> Alan. >> >> >> On Sun, May 21, 2017 at 4:35 PM, Darjus Loktevic <[hidden email]> wrote: >>> >>> Hey Guys, >>> >>> Regarding Jython3, looks like Isaiah has done a ton of work in 2016 >>> (CCd). Not sure how far he progressed, but indeed merging will be hard and >>> therefore I'd say we should not diverge further while developing on both >>> branches, but instead try to finalize 2.7 and switch to Jython3 full-time. >>> >>> Feel free to disagree, but here's my thinking on it: >>> >>> Release Jython 2.7.1 >>> Modernize the codebase. I think it's important for the project to feel >>> modern for us to attract new contributors. >>> >>> Java8 as the minimum (may be too much for Jython2). >>> Github/core-workflow >>> (Ideally) ANTLR4 for both branches, but worst case, Jython3 only. ANTLR3 >>> is not getting much love and ANTLR4 is quite different (does not generate >>> AST). >>> Gradle, directory structure. >>> >>> Develop Jython3 primarily. Only bugfixes for 2.7 series. >>> >>> Target 3.6 (really like the typing improvements). >>> Merge JyNI if possible. >>> >>> Cheers, >>> Darjus >>> >>> On Sat, May 20, 2017 at 11:45 PM Jeff Allen <[hidden email]> wrote: >>>> >>>> Thanks all. +1 on the RC. Nearly there with my bit. >>>> >>>> I have fixed the test_runpy failure James reported. It's not >>>> Linux-specific, just I had to quieten the unlink() error to see it on >>>> Windows. Bonus: we now pass the standard CPython test_runpy. The regrtest >>>> has been running one last time as I typed. I've pushed to >>>> https://bitbucket.org/tournesol/jython-utf8 just now. >>>> >>>> I will next merge into the Jython trunk. That may not be totally smooth >>>> because of the pervasive change. And now I think about it, it's worth a note >>>> in NEWS. My time is a little limited today, so it could be much later today >>>> or tomorrow evening. >>>> >>>> Jeff >>>> >>>> >>>> Jeff Allen >>>> >>>> On 20/05/2017 19:48, Jim Baker wrote: >>>> >>>> +100 >>>> >>>> On Sat, May 20, 2017 at 12:33 PM, Darjus Loktevic <[hidden email]> >>>> wrote: >>>>> >>>>> Agreed regarding not blocking on 2487. That whole area needs a rewrite >>>>> and we could potentially utilize libraries available for Java 8. >>>>> >>>>> Let's get Jeff's work in and do an RC? >>>>> >>>>> Darjus >>>>> > > > > ------------------------------------------------------------------------------ > 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 |
Re: Unicode user and file names (and v2.7.1)
|
|
Based on the discussion, I'm now against a 2.7.12, since the bugfix/micro part of the number shouldn't need to match CPython. Furthermore, sys.version and sys.version_info wouldn't be able to handle a 4th number. On May 22, 2017 17:59, "[hidden email]" <[hidden email]> wrote: I am in agreement with Stefan as well. I think making 2.7.x ------------------------------------------------------------------------------ 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 |
|
|
In reply to this post by Jim Baker-2
Just noticed guava > 20.0 requires Java 8.
Strange thing: When building and running Jython on Java 8 with guava 22.0 all regrtests pass fine, but jar-standalone build is bad. Seems like our ant task fails to copy com.google -> org.python.google. Note that I double and triple checked I adjusted build.xml correctly. Is this related to jarjar? Is it maybe not compatible with Java8 jar-files? This might become a problem at some point.
Studying guava 22.0 release notes more properly showed that one shall use guava-22.0-android.jar to target Java 7 also on non-Android platforms. With guava-22.0-android.jar, building Jython jar-standalone works well indeed. regrtests also seem to pass then.
Ideas?
I'll update the linked repo from last email with guava-22.0-android.jar...
Gesendet: Montag, 22. Mai 2017 um 17:22 Uhr
Von: "Jim Baker" <[hidden email]> An: "Stefan Richthofer" <[hidden email]> Cc: "Jython Developers" <[hidden email]> Betreff: Re: [Jython-dev] Updating extlibs These changes look good to me. I will test out your patch, but all of this is in line with similar updates we have made in the past, usually around this time in the dev cycle.
I'm glad that moving to Gradle will make this re-pinning to upstream dependencies much easier going forward!
On Mon, May 22, 2017 at 8:46 AM, Stefan Richthofer <[hidden email]> wrote:
I uploaded the mentioned updates to ------------------------------------------------------------------------------ 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 |
Re: Unicode user and file names (and v2.7.1)
|
|
In reply to this post by Stefan Richthofer
On Sat, May 20, 2017 at 5:00 PM, Stefan Richthofer
<[hidden email]> wrote: > I'd like to have http://bugs.jython.org/issue2536 "fixed" by removing that > infinite recursion test; maybe we could even close this annoying issue then. > A new Jython release should have reliable test suite. However I don't know > the best way to remove or blacklist a certain test. I don't think I saw anyone answer this (but the thread is long so I may have missed it) but if you look in regrtest.py you'll see a list starting around line 880, with one section called 'java'. That's a list of tests that are deliberately skipped. That list hasn't been looked at in a long time, and I bet there are tests in there that actually shouldn't get skipped anymore... but that's a whole different can of worms :) -Frank ------------------------------------------------------------------------------ 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 |
Re: Unicode user and file names (and v2.7.1)
|
|
On Tue, May 23, 2017 at 5:29 PM, [hidden email]
<[hidden email]> wrote: > On Sat, May 20, 2017 at 5:00 PM, Stefan Richthofer > <[hidden email]> wrote: >> I'd like to have http://bugs.jython.org/issue2536 "fixed" by removing that >> infinite recursion test; maybe we could even close this annoying issue then. >> A new Jython release should have reliable test suite. However I don't know >> the best way to remove or blacklist a certain test. > I don't think I saw anyone answer this (but the thread is long so I > may have missed it) but if you look in regrtest.py you'll see a list > starting around line 880, with one section called 'java'. That's a > list of tests that are deliberately skipped. That list hasn't been > looked at in a long time, and I bet there are tests in there that > actually shouldn't get skipped anymore... but that's a whole different > can of worms :) test file something like this decorating the particular test will work: @unittest.skipIf(test_support.is_jython, "Not a valid test for Jython") ------------------------------------------------------------------------------ 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 |
Re: Unicode user and file names (and v2.7.1)
|
|
Sorry, I should have taken Stefan's hint.
Yes, if we need to exclude a whole test, then there are lists in regrtest.py as Frank says. This is quite a crude tool, perhaps best suited to tests whose entire purpose is irrelevant to Jython or that interfere with subsequent tests. It is better to skip individual tests as Frank also indicates. Some tests really are not appropriate to Jython (mostly involving garbage collection) because Jython is different and we're happy with it that way. In other cases, it's a shortcoming of some kind and we should say so in the skip message. Ideally, the skip message or a comment in regrtest.py where the exclusion happens, according to the approach taken, links to an open issue. That way, we haven't just silenced the alarm. Jeff Jeff Allen On 24/05/2017 01:35, [hidden email] wrote: > On Tue, May 23, 2017 at 5:29 PM, [hidden email] > <[hidden email]> wrote: >> On Sat, May 20, 2017 at 5:00 PM, Stefan Richthofer >> <[hidden email]> wrote: >>> I'd like to have http://bugs.jython.org/issue2536 "fixed" by removing that >>> infinite recursion test; maybe we could even close this annoying issue then. >>> A new Jython release should have reliable test suite. However I don't know >>> the best way to remove or blacklist a certain test. >> I don't think I saw anyone answer this (but the thread is long so I >> may have missed it) but if you look in regrtest.py you'll see a list >> starting around line 880, with one section called 'java'. That's a >> list of tests that are deliberately skipped. That list hasn't been >> looked at in a long time, and I bet there are tests in there that >> actually shouldn't get skipped anymore... but that's a whole different >> can of worms :) > Or if you are talking about a single test function and not a whole > test file something like this decorating the particular test will > work: > > @unittest.skipIf(test_support.is_jython, "Not a valid test for Jython") > > ------------------------------------------------------------------------------ > 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 |
Re: Unicode user and file names (and v2.7.1)
|
|
Hey Jeff, Frank
thanks for coming back to this. However, I already helped myself to some extend. I wouldn't have asked if it was as simple as adding @skip. That's an option, but maybe not the "right" way (I should have been more specific). Specifically, the following tests should be excluded from test suite or moved to the very end (how to do that somewhat the "right" way?), because they potentially mess up guava internals such that later deadlocks can occur: test_json: Features its own test-suite, so not sure how well it is possible to exclude certain test files using regrtest.py, i.e. Lib/json/tests/test_recursion.py. Relevant tests to exclude from that file are: test_highly_nested_objects_decoding test_highly_nested_objects_encoding test_endless_recursion test_isinstance: test_subclass_recursion_limit test_isinstance_recursion_limit So, I'll just add @skipIf... to these, given that they are customized for Jython already, being in Lib. If you'd say we better exclude test_json and test_isinstance via regrtest.py or move them to the end, tell me... Maybe we'd better continue with this on bugtracker/#2536, if at all. Best -Stefan > Gesendet: Mittwoch, 24. Mai 2017 um 09:55 Uhr > Von: "Jeff Allen" <[hidden email]> > An: [hidden email] > Betreff: Re: [Jython-dev] Unicode user and file names (and v2.7.1) > > Sorry, I should have taken Stefan's hint. > > Yes, if we need to exclude a whole test, then there are lists in > regrtest.py as Frank says. This is quite a crude tool, perhaps best > suited to tests whose entire purpose is irrelevant to Jython or that > interfere with subsequent tests. > > It is better to skip individual tests as Frank also indicates. Some > tests really are not appropriate to Jython (mostly involving garbage > collection) because Jython is different and we're happy with it that > way. In other cases, it's a shortcoming of some kind and we should say > so in the skip message. > > Ideally, the skip message or a comment in regrtest.py where the > exclusion happens, according to the approach taken, links to an open > issue. That way, we haven't just silenced the alarm. > > Jeff > > Jeff Allen > > On 24/05/2017 01:35, [hidden email] wrote: > > On Tue, May 23, 2017 at 5:29 PM, [hidden email] > > <[hidden email]> wrote: > >> On Sat, May 20, 2017 at 5:00 PM, Stefan Richthofer > >> <[hidden email]> wrote: > >>> I'd like to have http://bugs.jython.org/issue2536 "fixed" by removing that > >>> infinite recursion test; maybe we could even close this annoying issue then. > >>> A new Jython release should have reliable test suite. However I don't know > >>> the best way to remove or blacklist a certain test. > >> I don't think I saw anyone answer this (but the thread is long so I > >> may have missed it) but if you look in regrtest.py you'll see a list > >> starting around line 880, with one section called 'java'. That's a > >> list of tests that are deliberately skipped. That list hasn't been > >> looked at in a long time, and I bet there are tests in there that > >> actually shouldn't get skipped anymore... but that's a whole different > >> can of worms :) > > Or if you are talking about a single test function and not a whole > > test file something like this decorating the particular test will > > work: > > > > @unittest.skipIf(test_support.is_jython, "Not a valid test for Jython") > > > > ------------------------------------------------------------------------------ > > 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 |
|
|
In reply to this post by Stefan Richthofer
Did someone test this on OSX? (reminder: https://github.com/Stewori/jython)
Or on Java 7?
I just tested on Java 7 and the only test I observe to fail unexpectedly is test_random:
test_random crashed -- <type 'exceptions.IOError'>: [Errno 13] Permission denied: '/data/workspace/linux/Jython_extlib/jython/dist/testreports/TEST-test.test_random.WichmannHill_TestBasicOps.xml'
The test passes when run individually.
However that is on my old laptop running Linux Mint Debian/LMDE2. It seems to be
some io error due to access rights and also occurs when running with Java8 on that
machine. Note that it passes with Java 8 on my current system. Unless this is due to
Java 8_111 vs Java 8_131, I guess it's system dependent. Strange though:
worked well before extlib update.
Still I'd suggest to get this stuff in for RC-phase, given that the test passes individually.
I'd merge this stuff as soon as someone reports OSX results.
-Stefan
Gesendet: Dienstag, 23. Mai 2017 um 23:57 Uhr
Von: "Stefan Richthofer" <[hidden email]> An: "Jim Baker" <[hidden email]> Cc: "Jython Developers" <[hidden email]> Betreff: Re: [Jython-dev] Updating extlibs Just noticed guava > 20.0 requires Java 8.
Strange thing: When building and running Jython on Java 8 with guava 22.0 all regrtests pass fine, but jar-standalone build is bad. Seems like our ant task fails to copy com.google -> org.python.google. Note that I double and triple checked I adjusted build.xml correctly. Is this related to jarjar? Is it maybe not compatible with Java8 jar-files? This might become a problem at some point.
Studying guava 22.0 release notes more properly showed that one shall use guava-22.0-android.jar to target Java 7 also on non-Android platforms. With guava-22.0-android.jar, building Jython jar-standalone works well indeed. regrtests also seem to pass then.
Ideas?
I'll update the linked repo from last email with guava-22.0-android.jar...
Gesendet: Montag, 22. Mai 2017 um 17:22 Uhr
Von: "Jim Baker" <[hidden email]> An: "Stefan Richthofer" <[hidden email]> Cc: "Jython Developers" <[hidden email]> Betreff: Re: [Jython-dev] Updating extlibs These changes look good to me. I will test out your patch, but all of this is in line with similar updates we have made in the past, usually around this time in the dev cycle.
I'm glad that moving to Gradle will make this re-pinning to upstream dependencies much easier going forward!
On Mon, May 22, 2017 at 8:46 AM, Stefan Richthofer <[hidden email]> wrote:
I uploaded the mentioned updates to ------------------------------------------------------------------------------ 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 |
Re: Unicode user and file names (and v2.7.1)
|
|
In reply to this post by Stefan Richthofer
If it messes up later tests then, until it can be fixed, I think the
apparatus we have for excluding it applies. However, an extra test that would fail in that case might be a good addition. BTW when diagnosing that kind of thing, I've found it useful that regrtest takes a list of tests on the command line, or in a file, and runs them in the order given (and as many times as given). +1 for adding fine-grain skips as you intend, mentioning the most appropriate issue. Jeff Allen On 24/05/2017 17:27, Stefan Richthofer wrote: > Hey Jeff, Frank > > thanks for coming back to this. However, I already helped myself to some extend. > I wouldn't have asked if it was as simple as adding @skip. That's an option, but maybe not the "right" way (I should have been more specific). > > Specifically, the following tests should be excluded from test suite or moved to the very end (how to do that somewhat the "right" way?), because they potentially mess up guava internals such that later deadlocks can occur: > > test_json: Features its own test-suite, so not sure how well it is possible to exclude certain test files using regrtest.py, i.e. Lib/json/tests/test_recursion.py. Relevant tests to exclude from that file are: > > test_highly_nested_objects_decoding > test_highly_nested_objects_encoding > test_endless_recursion > > > test_isinstance: > test_subclass_recursion_limit > test_isinstance_recursion_limit > > So, I'll just add @skipIf... to these, given that they are customized for Jython already, being in Lib. If you'd say we better exclude test_json and test_isinstance via regrtest.py or move them to the end, tell me... > Maybe we'd better continue with this on bugtracker/#2536, if at all. > > Best > > -Stefan > > >> Gesendet: Mittwoch, 24. Mai 2017 um 09:55 Uhr >> Von: "Jeff Allen" <[hidden email]> >> An: [hidden email] >> Betreff: Re: [Jython-dev] Unicode user and file names (and v2.7.1) >> >> Sorry, I should have taken Stefan's hint. >> >> Yes, if we need to exclude a whole test, then there are lists in >> regrtest.py as Frank says. This is quite a crude tool, perhaps best >> suited to tests whose entire purpose is irrelevant to Jython or that >> interfere with subsequent tests. >> >> It is better to skip individual tests as Frank also indicates. Some >> tests really are not appropriate to Jython (mostly involving garbage >> collection) because Jython is different and we're happy with it that >> way. In other cases, it's a shortcoming of some kind and we should say >> so in the skip message. >> >> Ideally, the skip message or a comment in regrtest.py where the >> exclusion happens, according to the approach taken, links to an open >> issue. That way, we haven't just silenced the alarm. >> >> Jeff >> >> Jeff Allen >> >> On 24/05/2017 01:35, [hidden email] wrote: >>> On Tue, May 23, 2017 at 5:29 PM, [hidden email] >>> <[hidden email]> wrote: >>>> On Sat, May 20, 2017 at 5:00 PM, Stefan Richthofer >>>> <[hidden email]> wrote: >>>>> I'd like to have http://bugs.jython.org/issue2536 "fixed" by removing that >>>>> infinite recursion test; maybe we could even close this annoying issue then. >>>>> A new Jython release should have reliable test suite. However I don't know >>>>> the best way to remove or blacklist a certain test. >>>> I don't think I saw anyone answer this (but the thread is long so I >>>> may have missed it) but if you look in regrtest.py you'll see a list >>>> starting around line 880, with one section called 'java'. That's a >>>> list of tests that are deliberately skipped. That list hasn't been >>>> looked at in a long time, and I bet there are tests in there that >>>> actually shouldn't get skipped anymore... but that's a whole different >>>> can of worms :) >>> Or if you are talking about a single test function and not a whole >>> test file something like this decorating the particular test will >>> work: >>> >>> @unittest.skipIf(test_support.is_jython, "Not a valid test for Jython") >>> >>> ------------------------------------------------------------------------------ >>> 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 |
|
|
In reply to this post by Stefan Richthofer
Stefan, You can apply these updates to extlibs, based on my testing on OSX. More below. I was able to run the following on both Java 7 and Java 8 on OSX: pip/setuptools installation smoke test fully succeeds, using the manual test described in http://bugs.jython.org/issue2570 (we should look at automating, at least with a simple bash script) regrtest. I did observe flakiness in test_socket_jy, which may require more rounds of waiting, but it does not appear to happen unless it's run in the context of other tests, so full runs of the regrtest. (And IIRC, appeared in the past before extlib update. It has been a well-known flaky test.) For Java 7, test_codecencodings_tw continues to not completely pass, almost certainly due to changes in underlying Java support (a bug fix that was not applied to Java 7). It has nothing to do with these extlib updates. Note that test_socket is shaking out some problems, likely due to the Netty update further refining the exceptions it throws. It's worth noting that error states are not documented very well for either C sockets or Netty's rather different support, so we have to explore the implemented behavior. So one example I saw that should be fixed at some point (possibly not for 2.7.1, there will always be more bugs, and certainly higher priority ones IMHO at this time): [exec] Unhandled exception in thread started by <bound method BasicTCPTest.clientRun of testShutdown (test.test_socket.BasicTCPTest)> [exec] Traceback (most recent call last): [exec] File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/test/test_socket.py", line 186, in clientRun [exec] self.clientSetUp() [exec] File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/test/test_socket.py", line 246, in clientSetUp [exec] self.cli.connect((self.HOST, self.PORT)) [exec] File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 1441, in meth [exec] return getattr(self._sock,name)(*args) [exec] File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 935, in connect [exec] self._connect(addr) [exec] File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 911, in _connect [exec] self._handle_channel_future(self.connect_future, "connect") [exec] File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 384, in handle_exception [exec] raise _map_exception(jlx) [exec] _socket.error: [Errno -1] Unmapped exception: io.netty.channel.AbstractChannel$AnnotatedSocketException: Invalid argument: localhost/127.0.0.1:50100 I was unable to see this error thrown again, but we may have enough to still fix in the exception mapping code. - Jim On Wed, May 24, 2017 at 1:26 PM, Stefan Richthofer <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 |
|
|
> You can apply these updates to extlibs
Done as of https://hg.python.org/jython/rev/f6b3ddbc1df8.
From my point of view we can launch Jython 2.7.1-RC2 now.
- no open PRs on github left
- no release blockers left apparently
- all updates done as far as possible (python std-lib will be next challenge on this front)
So, I'd suggest everybody pushes last-minute work and Frank hits the release-button... :-)
What do you think?
Cheers!
-Stefan
Gesendet: Freitag, 26. Mai 2017 um 20:16 Uhr
Von: "Jim Baker" <[hidden email]> An: "Stefan Richthofer" <[hidden email]> Cc: "Jython Developers" <[hidden email]> Betreff: Re: [Jython-dev] Updating extlibs Stefan,
You can apply these updates to extlibs, based on my testing on OSX. More below.
I was able to run the following on both Java 7 and Java 8 on OSX:
pip/setuptools installation smoke test fully succeeds, using the manual test described in http://bugs.jython.org/issue2570 (we should look at automating, at least with a simple bash script)
regrtest. I did observe flakiness in test_socket_jy, which may require more rounds of waiting, but it does not appear to happen unless it's run in the context of other tests, so full runs of the regrtest. (And IIRC, appeared in the past before extlib update. It has been a well-known flaky test.) For Java 7, test_codecencodings_tw continues to not completely pass, almost certainly due to changes in underlying Java support (a bug fix that was not applied to Java 7). It has nothing to do with these extlib updates.
Note that test_socket is shaking out some problems, likely due to the Netty update further refining the exceptions it throws. It's worth noting that error states are not documented very well for either C sockets or Netty's rather different support, so we have to explore the implemented behavior. So one example I saw that should be fixed at some point (possibly not for 2.7.1, there will always be more bugs, and certainly higher priority ones IMHO at this time):
[exec] Unhandled exception in thread started by <bound method BasicTCPTest.clientRun of testShutdown (test.test_socket.BasicTCPTest)>
[exec] Traceback (most recent call last):
[exec] File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/test/test_socket.py", line 186, in clientRun
[exec] self.clientSetUp()
[exec] File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/test/test_socket.py", line 246, in clientSetUp
[exec] self.cli.connect((self.HOST, self.PORT))
[exec] File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 1441, in meth
[exec] return getattr(self._sock,name)(*args)
[exec] File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 935, in connect
[exec] self._connect(addr)
[exec] File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 911, in _connect
[exec] self._handle_channel_future(self.connect_future, "connect")
[exec] File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 384, in handle_exception
[exec] raise _map_exception(jlx)
[exec] _socket.error: [Errno -1] Unmapped exception: io.netty.channel.AbstractChannel$AnnotatedSocketException: Invalid argument: localhost/127.0.0.1:50100
I was unable to see this error thrown again, but we may have enough to still fix in the exception mapping code.
- Jim
On Wed, May 24, 2017 at 1:26 PM, Stefan Richthofer <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 |
|
|
Agreed. It's time for putting this release candidate out! I'm also glad about the timing, because this mean Stefan has a great base to build this summer's work on JyNI. I believe it's technically RC1 still because the last RC was a soft release, but Frank knows those specifics. I just ran the "yolk smoke test" from http://bugs.jython.org/ After this we can look into: 1. Finally get jython.org revamped. I suggest the simplicity — and modern look — of GitHub pages, where we can host and then point jython.org accordingly. 2. Switch to the Gradle build that Darjus has been working on 3. Cut over to https://github.com/jython/jython with rewritten history that removes extlib jars for a subsequent release of 2.7.x, where x > 1 (maybe it's 12 for the next release, but we can decide later). Lastly, I also felt it was important to highlight Stefan's contribution to helping finalize 2.7.1, as well as our appreciation to Google for supporting him this summer for the Google Summer of Code. First win for GSOC 2017 in other words. Duly noted as of https://hg.python.org/jython/rev/ab5434be88aa - Jim On May 26, 2017 7:24 PM, "Stefan Richthofer" <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 |
2.7.1rc, to infinity and beyond!
|
|
Excellent news! A lot has gone on between 2.7.0 and 2.7.1. it's good to
find we've all feel "done"at the same time :) Small typo in your front page: "many others to thanks". I have a weak preference for calling it RC2 given there was change after RC1. I think RC1 still identifies a release, even if it was announced softly, and what we have now is different. There's a bit more to cutting over to Git than declaring it so. I've been watching CPython do this with the corner of one eye. We will have both bugs.jython.org and Git pull requests for a while ... essentially forever. There was some integration work (which we should steal, but that depends, I suspect, on upgrading the tracker) and conventions for how to refer to one from the other. It was tough at points because of disagreement on how it were best done, but we can just go along with their conclusion. And s/bpo/bjo/. Jeff Allen On 27/05/2017 01:12, Jim Baker wrote: > Agreed. It's time for putting this release candidate out! I'm also > glad about the timing, because this mean Stefan has a great base to > build this summer's work on JyNI. I believe it's technically RC1 still > because the last RC was a soft release, but Frank knows those specifics. > > I just ran the "yolk smoke test" from http://bugs.jython.org/issue2570 > <http://bugs.jython.org/issue2570> one last time, just to make sure. > Everything looks great! > > After this we can look into: > > 1. Finally get jython.org <http://jython.org> revamped. I suggest the > simplicity — and modern look — of GitHub pages, where we can host and > then point jython.org <http://jython.org> accordingly. > 2. Switch to the Gradle build that Darjus has been working on > 3. Cut over to https://github.com/jython/jython with rewritten history > that removes extlib jars for a subsequent release of 2.7.x, where x > > 1 (maybe it's 12 for the next release, but we can decide later). > > Lastly, I also felt it was important to highlight Stefan's > contribution to helping finalize 2.7.1, as well as our appreciation to > Google for supporting him this summer for the Google Summer of Code. > First win for GSOC 2017 in other words. Duly noted as of > https://hg.python.org/jython/rev/ab5434be88aa > > - Jim > > > > On May 26, 2017 7:24 PM, "Stefan Richthofer" <[hidden email] > <mailto:[hidden email]>> wrote: > > > You can apply these updates to extlibs > Done as of https://hg.python.org/jython/rev/f6b3ddbc1df8 > <https://hg.python.org/jython/rev/f6b3ddbc1df8>. > From my point of view we can launch Jython 2.7.1-RC2 now. > - no open PRs on github left > - no release blockers left apparently except #2487 > - all updates done as far as possible (python std-lib will be next > challenge on this front) > So, I'd suggest everybody pushes last-minute work and Frank hits > the release-button... :-) > What do you think? > Cheers! > -Stefan > ------------------------------------------------------------------------------ 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 |
Re: 2.7.1rc, to infinity and beyond!
|
|
I know I'm a lurker and not an active dev, but I'd prefer the rc2 name as well, fwiw. Cheers Adam On 27 May 2017 at 15:33, Jeff Allen <[hidden email]> wrote: Excellent news! A lot has gone on between 2.7.0 and 2.7.1. it's good to find we've all feel "done"at the same time :) ------------------------------------------------------------------------------ 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 |
Re: 2.7.1rc, to infinity and beyond!
|
|
Updated README to state RC2, plus fixed the typo. Thanks for the feedback! Agreed that getting on github will not be the most minor fix (!), but it will be worth the effort. I do like Mercurial, and very much appreciate the Hg team's help in moving Jython to hg.python.org from Subversion. Nonetheless, we found out in using Mercurial for the last 5 or so years for Jython development that it didn't match our development processes. It's both time to move on, and join CPython upstream in its dev processes. On Sat, May 27, 2017 at 5:07 AM, Adam Burke <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 |
Re: 2.7.1rc, to infinity and beyond!
|
|
Great news, and amazing work everyone! I'll get the soft release together this weekend. If there are no troubles, I'll get the hard RC2 out next week. On May 27, 2017 10:46, "Jim Baker" <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 |
Re: 2.7.1rc, to infinity and beyond!
|
|
> Agreed that getting on github will not be the most minor fix
It occurred to me that this change actually aligns with our focus shift to Jython 3. Maybe we can benefit from this by setting up the new workflow only for Jython 3. Then it would be kind of a reboot rather than a (potentially painful) migration. It would naturaly sort out Jython 3 stuff from Jython 2 stuff. (We could even consider to track Jython 3 issues on github and continue bjo just for Jython 2.) Think about it. > I also felt it was important to highlight Stefan's contribution to helping finalize 2.7.1
It's a great honor for me to be mentioned for this. Thank you very much! Looking at ACKNOWLEDGEMENTS I found that the file does not explicitly display who is actually core-developing Jython right now. Jeff, Jim, Darjus and Frank who are putting a lot of work into Jython (or did so in the last years) are mentioned randomly between all contributors, including persons with really minimal contributions (don't get me wrong - every contribution is very valuable!). While this is a very modest attitude I think the (active) core-dev team should be explicitly named somewhere at the beginning of the file, not lastly because users might need this info to assess who to ask. Also - maybe I overlooked it - it is nowhere stated that Frank is the project lead. This should be made clear IMO. In case we decided to add such a section I'd suggest to also mention James Mudd, at least for this release, because he spent significantly more work on Jython than the average contributor. > I'll get the soft release together this weekend. If there are no troubles, I'll get the hard RC2 out next week.
Looking forward to it! Thanks a lot. Best regards -Stefan
Gesendet: Samstag, 27. Mai 2017 um 20:43 Uhr
Von: "[hidden email]" <[hidden email]> An: "Jim Baker" <[hidden email]> Cc: "Jython Developers" <[hidden email]> Betreff: Re: [Jython-dev] 2.7.1rc, to infinity and beyond! Great news, and amazing work everyone! I'll get the soft release together this weekend. If there are no troubles, I'll get the hard RC2 out next week.
On May 27, 2017 10:46, "Jim Baker" <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 |
Re: 2.7.1rc, to infinity and beyond!
|
|
Just a few comments from my point of view. I think moving to a Github based workflow will help to attract more contributors to Jython. I just think more people are familiar with the workflow, so it's less effort to get involved, even minor things like having to sign up to bugs.jython.org might put people off. Having said that I really hope more people get involved. I have really enjoyed putting some work into Jython, and have got to investigate some interesting bugs which has been really fun. I think its a unique kind of project which is really interesting to work on, and all the other contributors seem to be really friendly and helpful. I hope to keep contributing in the future when time allows. Also thanks to Stefan for the comments, and the great discussion on many of the bugs fixed over the last few months, as well as merging many of my suggested patches. Looking forward to seeing the RC2, and hopefully soon after the final release. James On 28 May 2017 at 19:11, Stefan Richthofer <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 |
Re: 2.7.1rc, to infinity and beyond!
|
|
+1 on Stefan's suggestion that we simply start as we mean to go on with
Jython 3 on GitHub. We still must choose a workflow and make it known. This might be a change of practice for those of us with direct commit rights, away from commit-then-review, to something based on PRs. I was always a bit surprised we did not have such a two-step process with Mercurial. Concerning identifying the value of individuals' contributions, I think we enter a minefield. It seems to be the Python way that we're all just names in a big flat acknowledgements file, however large or small our contribution. I saw this principle enunciated by Guido on python-dev. (Sorry, can't find it now.) Oh, now I look, it's loosely what the ACKS file itself says. I think it more practical to talk about what trust the project accords someone, which brings us back to workflow. On CPython there's an identified set of core developers who have the right (and are relied upon) to review others' contributions and commit them to the project repository -- being trusted to know their own competence. That is worth being clearer about for Jython, especially if someone has commit rights in practice but we don't expect them to review PRs/patches. On GitHub, some of us are members and others owners, but I don't know what is intended by that. There was some debate in CPython about the new workflow, whether code devs could review and accept their own work. I think there should normally be at least the opportunity for peer review if work is a large change ... something like I did for the 2.7.1 changes to the buffer interface and UTF-8 fix. In the unique case of the project lead, I believe Frank's status is a PSF appointment. I have seen that in documentation somewhere, but why not more prominently? Jeff Allen On 28/05/2017 21:45, James Mudd wrote: > Just a few comments from my point of view. > > I think moving to a Github based workflow will help to attract more > contributors to Jython. I just think more people are familiar with the > workflow, so it's less effort to get involved, even minor things like > having to sign up to bugs.jython.org <http://bugs.jython.org> might > put people off. Having said that I really hope more people get > involved. I have really enjoyed putting some work into Jython, and > have got to investigate some interesting bugs which has been really > fun. I think its a unique kind of project which is really interesting > to work on, and all the other contributors seem to be really friendly > and helpful. I hope to keep contributing in the future when time allows. > > Also thanks to Stefan for the comments, and the great discussion on > many of the bugs fixed over the last few months, as well as merging > many of my suggested patches. > > Looking forward to seeing the RC2, and hopefully soon after the final > release. > > James > > On 28 May 2017 at 19:11, Stefan Richthofer <[hidden email] > <mailto:[hidden email]>> wrote: > > > Agreed that getting on github will not be the most minor fix > > It occurred to me that this change actually aligns with our focus > shift to Jython 3. Maybe we can benefit from this by setting up > the new workflow only for Jython 3. Then it would be kind of a > reboot rather than a (potentially painful) migration. It would > naturaly sort out Jython 3 stuff from Jython 2 stuff. (We could > even consider to track Jython 3 issues on github and continue bjo > just for Jython 2.) Think about it. > > I also felt it was important to highlight Stefan's contribution to helping finalize 2.7.1 > > It's a great honor for me to be mentioned for this. Thank you very > much! > Looking at ACKNOWLEDGEMENTS I found that the file does not > explicitly display who is actually core-developing Jython right > now. Jeff, Jim, Darjus and Frank who are putting a lot of work > into Jython (or did so in the last years) are mentioned randomly > between all contributors, including persons with really minimal > contributions (don't get me wrong - every contribution is very > valuable!). While this is a very modest attitude I think the > (active) core-dev team should be explicitly named somewhere at the > beginning of the file, not lastly because users might need this > info to assess who to ask. Also - maybe I overlooked it - it is > nowhere stated that Frank is the project lead. This should be made > clear IMO. In case we decided to add such a section I'd suggest to > also mention James Mudd, at least for this release, because he > spent significantly more work on Jython than the average contributor. > > I'll get the soft release together this weekend. If there are no troubles, I'll get the hard RC2 out next > week. > > Looking forward to it! Thanks a lot. > > Best regards > -Stefan > *Gesendet:* Samstag, 27. Mai 2017 um 20:43 Uhr > *Von:* "[hidden email] <mailto:[hidden email]>" > <[hidden email] <mailto:[hidden email]>> > *An:* "Jim Baker" <[hidden email] <mailto:[hidden email]>> > *Cc:* "Jython Developers" <[hidden email] > <mailto:[hidden email]>> > *Betreff:* Re: [Jython-dev] 2.7.1rc, to infinity and beyond! > Great news, and amazing work everyone! I'll get the soft release > together this weekend. If there are no troubles, I'll get the hard > RC2 out next week. > On May 27, 2017 10:46, "Jim Baker" <[hidden email] > <mailto:[hidden email]>> wrote: > > Updated README to state RC2, plus fixed the typo. Thanks for > the feedback! > Agreed that getting on github will not be the most minor fix > (!), but it will be worth the effort. I do like Mercurial, and > very much appreciate the Hg team's help in moving Jython to > hg.python.org <http://hg.python.org> from Subversion. > Nonetheless, we found out in using Mercurial for the last 5 or > so years for Jython development that it didn't match our > development processes. It's both time to move on, and join > CPython upstream in its dev processes. > On Sat, May 27, 2017 at 5:07 AM, Adam Burke > <[hidden email] <mailto:[hidden email]>> wrote: > > I know I'm a lurker and not an active dev, but I'd prefer > the rc2 name as well, fwiw. > Cheers > Adam > On 27 May 2017 at 15:33, Jeff Allen <[hidden email] > <mailto:[hidden email]>> wrote: > > Excellent news! A lot has gone on between 2.7.0 and > 2.7.1. it's good to find we've all feel "done"at the > same time :) > > Small typo in your front page: "many others to thanks". > > I have a weak preference for calling it RC2 given > there was change after RC1. I think RC1 still > identifies a release, even if it was announced softly, > and what we have now is different. > > There's a bit more to cutting over to Git than > declaring it so. I've been watching CPython do this > with the corner of one eye. We will have both > bugs.jython.org <http://bugs.jython.org> and Git pull > requests for a while ... essentially forever. There > was some integration work (which we should steal, but > that depends, I suspect, on upgrading the tracker) and > conventions for how to refer to one from the other. It > was tough at points because of disagreement on how it > were best done, but we can just go along with their > conclusion. And s/bpo/bjo/. > > Jeff Allen > > On 27/05/2017 01:12, Jim Baker wrote: > > Agreed. It's time for putting this release > candidate out! I'm also glad about the timing, > because this mean Stefan has a great base to build > this summer's work on JyNI. I believe it's > technically RC1 still because the last RC was a > soft release, but Frank knows those specifics. > > I just ran the "yolk smoke test" from > http://bugs.jython.org/issue2570 > <http://bugs.jython.org/issue2570> > <http://bugs.jython.org/issue2570 > <http://bugs.jython.org/issue2570>> one last time, > just to make sure. Everything looks great! > > After this we can look into: > > 1. Finally get jython.org <http://jython.org> > <http://jython.org> revamped. I suggest the > simplicity — and modern look — of GitHub pages, > where we can host and then point jython.org > <http://jython.org> <http://jython.org> accordingly. > 2. Switch to the Gradle build that Darjus has been > working on > 3. Cut over to https://github.com/jython/jython > <https://github.com/jython/jython> with rewritten > history that removes extlib jars for a subsequent > release of 2.7.x, where x > 1 (maybe it's 12 for > the next release, but we can decide later). > > Lastly, I also felt it was important to highlight > Stefan's contribution to helping finalize 2.7.1, > as well as our appreciation to Google for > supporting him this summer for the Google Summer > of Code. First win for GSOC 2017 in other words. > Duly noted as of > https://hg.python.org/jython/rev/ab5434be88aa > <https://hg.python.org/jython/rev/ab5434be88aa> > > - Jim > > > > On May 26, 2017 7:24 PM, "Stefan Richthofer" > <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> wrote: > > > You can apply these updates to extlibs > Done as of > https://hg.python.org/jython/rev/f6b3ddbc1df8 > <https://hg.python.org/jython/rev/f6b3ddbc1df8> > <https://hg.python.org/jython/rev/f6b3ddbc1df8 > <https://hg.python.org/jython/rev/f6b3ddbc1df8>>. > From my point of view we can launch Jython > 2.7.1-RC2 now. > - no open PRs on github left > - no release blockers left apparently except #2487 > - all updates done as far as possible (python > std-lib will be next > challenge on this front) > So, I'd suggest everybody pushes last-minute > work and Frank hits > the release-button... :-) > What do you think? > Cheers! > -Stefan > > <snip> > > ------------------------------------------------------------------------------ > 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] > <mailto:[hidden email]> > https://lists.sourceforge.net/lists/listinfo/jython-dev > <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] > <mailto:[hidden email]> > https://lists.sourceforge.net/lists/listinfo/jython-dev > <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] > <mailto:[hidden email]> > https://lists.sourceforge.net/lists/listinfo/jython-dev > <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_______________________________________________ > <http://sdm.link/slashdot_______________________________________________> > Jython-dev mailing list [hidden email] > <mailto:[hidden email]> > https://lists.sourceforge.net/lists/listinfo/jython-dev > <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] > <mailto:[hidden email]> > https://lists.sourceforge.net/lists/listinfo/jython-dev > <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 |
«
Return to jython-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |