Menu
▾
▴
jython-dev — Discussion of developing and enhancing Jython itself(!) (not how to use Jython)
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(38) |
Nov
(98) |
Dec
(58) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(114) |
Feb
(123) |
Mar
(96) |
Apr
(66) |
May
(84) |
Jun
(72) |
Jul
(128) |
Aug
(126) |
Sep
(82) |
Oct
(80) |
Nov
(148) |
Dec
(55) |
| 2002 |
Jan
(137) |
Feb
(85) |
Mar
(118) |
Apr
(67) |
May
(71) |
Jun
(28) |
Jul
(69) |
Aug
(48) |
Sep
(83) |
Oct
(79) |
Nov
(54) |
Dec
(32) |
| 2003 |
Jan
(44) |
Feb
(47) |
Mar
(59) |
Apr
(57) |
May
(43) |
Jun
(45) |
Jul
(44) |
Aug
(39) |
Sep
(27) |
Oct
(62) |
Nov
(17) |
Dec
(23) |
| 2004 |
Jan
(41) |
Feb
(51) |
Mar
(38) |
Apr
(30) |
May
(25) |
Jun
(12) |
Jul
(11) |
Aug
(27) |
Sep
(16) |
Oct
(56) |
Nov
(23) |
Dec
(29) |
| 2005 |
Jan
(75) |
Feb
(82) |
Mar
(50) |
Apr
(77) |
May
(19) |
Jun
(104) |
Jul
(47) |
Aug
(42) |
Sep
(28) |
Oct
(143) |
Nov
(62) |
Dec
(13) |
| 2006 |
Jan
(20) |
Feb
(10) |
Mar
(59) |
Apr
(45) |
May
(25) |
Jun
(129) |
Jul
(162) |
Aug
(91) |
Sep
(15) |
Oct
(39) |
Nov
(186) |
Dec
(191) |
| 2007 |
Jan
(134) |
Feb
(140) |
Mar
(106) |
Apr
(77) |
May
(92) |
Jun
(63) |
Jul
(233) |
Aug
(102) |
Sep
(119) |
Oct
(63) |
Nov
(68) |
Dec
(32) |
| 2008 |
Jan
(69) |
Feb
(91) |
Mar
(129) |
Apr
(44) |
May
(18) |
Jun
(53) |
Jul
(50) |
Aug
(25) |
Sep
(11) |
Oct
(28) |
Nov
(67) |
Dec
(36) |
| 2009 |
Jan
(20) |
Feb
(24) |
Mar
(66) |
Apr
(53) |
May
(48) |
Jun
(48) |
Jul
(59) |
Aug
(82) |
Sep
(49) |
Oct
(30) |
Nov
(16) |
Dec
(16) |
| 2010 |
Jan
(52) |
Feb
(25) |
Mar
(36) |
Apr
(34) |
May
(14) |
Jun
(15) |
Jul
(14) |
Aug
(16) |
Sep
(23) |
Oct
(6) |
Nov
(4) |
Dec
(5) |
| 2011 |
Jan
(4) |
Feb
(22) |
Mar
(45) |
Apr
(9) |
May
(8) |
Jun
(13) |
Jul
(12) |
Aug
(4) |
Sep
(6) |
Oct
(10) |
Nov
(21) |
Dec
(5) |
| 2012 |
Jan
(6) |
Feb
(9) |
Mar
(25) |
Apr
(6) |
May
(4) |
Jun
(23) |
Jul
(6) |
Aug
(18) |
Sep
(21) |
Oct
(34) |
Nov
(19) |
Dec
(25) |
| 2013 |
Jan
(8) |
Feb
(34) |
Mar
(35) |
Apr
(4) |
May
(11) |
Jun
(4) |
Jul
(7) |
Aug
(5) |
Sep
(20) |
Oct
(12) |
Nov
(11) |
Dec
(7) |
| 2014 |
Jan
(10) |
Feb
(18) |
Mar
(50) |
Apr
(26) |
May
(53) |
Jun
(21) |
Jul
(12) |
Aug
(39) |
Sep
(43) |
Oct
(26) |
Nov
(8) |
Dec
(6) |
| 2015 |
Jan
(18) |
Feb
(32) |
Mar
(31) |
Apr
(42) |
May
(38) |
Jun
(13) |
Jul
(6) |
Aug
(11) |
Sep
(29) |
Oct
(25) |
Nov
(10) |
Dec
(11) |
| 2016 |
Jan
(24) |
Feb
(12) |
Mar
(13) |
Apr
(15) |
May
(22) |
Jun
(8) |
Jul
(12) |
Aug
(25) |
Sep
(8) |
Oct
(6) |
Nov
(13) |
Dec
(7) |
| 2017 |
Jan
(6) |
Feb
(29) |
Mar
(32) |
Apr
(8) |
May
(82) |
Jun
(42) |
Jul
(20) |
Aug
(17) |
Sep
(27) |
Oct
(14) |
Nov
(22) |
Dec
(6) |
| 2018 |
Jan
(12) |
Feb
(9) |
Mar
(22) |
Apr
(19) |
May
(14) |
Jun
(9) |
Jul
(9) |
Aug
(22) |
Sep
(22) |
Oct
(12) |
Nov
(13) |
Dec
(8) |
| 2019 |
Jan
(22) |
Feb
(3) |
Mar
(30) |
Apr
(20) |
May
(20) |
Jun
(6) |
Jul
(15) |
Aug
(25) |
Sep
(11) |
Oct
(24) |
Nov
(11) |
Dec
(6) |
| 2020 |
Jan
(9) |
Feb
(12) |
Mar
(29) |
Apr
(10) |
May
(22) |
Jun
(11) |
Jul
(15) |
Aug
(5) |
Sep
(6) |
Oct
(7) |
Nov
(7) |
Dec
(13) |
| 2021 |
Jan
(21) |
Feb
(5) |
Mar
(5) |
Apr
(6) |
May
(10) |
Jun
(7) |
Jul
(6) |
Aug
(8) |
Sep
(5) |
Oct
(9) |
Nov
(5) |
Dec
(6) |
| 2022 |
Jan
(5) |
Feb
(4) |
Mar
(8) |
Apr
(6) |
May
(5) |
Jun
(5) |
Jul
(10) |
Aug
(6) |
Sep
(7) |
Oct
(4) |
Nov
(4) |
Dec
(6) |
| 2023 |
Jan
(5) |
Feb
(5) |
Mar
(6) |
Apr
(4) |
May
(5) |
Jun
(6) |
Jul
(5) |
Aug
(5) |
Sep
(5) |
Oct
(5) |
Nov
(7) |
Dec
(8) |
| 2024 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2025 |
Jan
|
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <fwi...@gm...> - 2019-10-09 05:42:54
|
On Tue, Oct 8, 2019 at 12:58 PM Jeff Allen <ja...@fa...> wrote: > > Ok, let's do it! Great! I have started giving it a try locally but have run into a few problems. I'm pretty sure all of the problems are on me - I will reach out if I think I need help. I'll keep trying tonight but I think getting my cobwebs out of my environment is probably going to take more than one day. I will keep you posted. -Frank |
|
From: Jeff A. <ja...@fa...> - 2019-10-08 19:59:11
|
Ok, let's do it! I have pushed the changesets I made when I did the last dry run (the metadata changes and the tag). This means that in the documented process, sections 23.1.3, 23.1.6 and 23.1.10 are already taken care of. I did the tests leading up to 23.1.10, but feel free to repeat enough of them to protect our reputation. This full build has only ever run on a Windows machine, so far as I know, so there is definitely scope for latent bugs. When it comes to building the bundles, I think I reproduced what was there before, but it is entirely untested by me. There is a new bundle for jython-slim. There are sections of |maven/build.xml| that looked like contingent work-arounds and I'm unable to fix/test the ones that involve the bundles. Good luck! Jeff Allen On 06/10/2019 20:33, fwi...@gm... wrote: > On Sun, Oct 6, 2019 at 2:56 AM Jeff Allen <ja...@fa...> wrote: >> I think the version of Jython now at the repo tip is, apart from changing the metadata, a viable Jython 2.7.2 beta. >> >> I have dry run the process several times to the point where I can make the artefacts that would go to Sonatype, at least as far as I can test that. I have ironed out the problems (as they arise on my machine) and worked on the ant scripts. I think it's a straight run now for Frank to build and publish. >> >> The process is here: https://jython-devguide.readthedocs.io/en/latest/release_jy.html > When I build and upload I'll see if these docs need updating. > >> I have bumped Jython up to Java 8. This broke a few things, now resolved. JarJar does not translate the later bytecode in the version we had used. (See issue 2806.) And Java 8 is picky about Javadoc, where apparently we've not been good :o(. I fixed over a hundred javadoc errors, but I'm leaving the warnings for a later burst of enthusiasm. >> >> A lot of bugs are fixed in this release and some features added as noted in NEWS. I still have misgivings around the number of suppressed tests (and so many places we can do it), and the way tests involving networking (SSL and Netty) contiunue to be flakey. The socket-related modules are an awesome achievement, but incomplete in some ways. However, one must not let the defects dominate one's thinking. So much is good and improved in 2.7.2, and this includes all the issues we prioritised in the triage. >> > This is great news! > >> What do others think? Tag it? > Yes, tag it! I agree with Jim that this should be tagged as a beta > release. I confirmed that my sonatype login still works, I'm happy to > test out the release process and get this published. While I'm there > I'll poke around to see if I can find out how new users are added. > >> Jeff >> >> -- >> Jeff Allen |
|
From: Jeff A. <ja...@fa...> - 2019-10-06 19:59:32
|
On 06/10/2019 17:52, Jim Baker wrote: > Jeff, > > I'm glad to hear this great news! We should proceed now as you > suggest, given that you have reached the far as you can tell point in > the testing process. I doubt anyone will disagree, but I thought I'd give a couple of days for others to respond. > > So let's use this beta to shake out the release process. At this point > in this release cycle, our code quality and corresponding testing is > very good, so it should not be considered an alpha. Future releases > can build further and also provide more assurance on shrinking the > time to subsequent releases. Gradle support is a good example here. > > One nit: there's still an obsolete reference to Java 7 in > https://jython-devguide.readthedocs.io/en/latest/release_jy.html : > "At the time of writing we target Java 7." > Ah yes. And in the following code display too. Thanks for reading carefully. I'll fix that. Jeff |
|
From: <fwi...@gm...> - 2019-10-06 19:34:32
|
On Sun, Oct 6, 2019 at 2:56 AM Jeff Allen <ja...@fa...> wrote: > > I think the version of Jython now at the repo tip is, apart from changing the metadata, a viable Jython 2.7.2 beta. > > I have dry run the process several times to the point where I can make the artefacts that would go to Sonatype, at least as far as I can test that. I have ironed out the problems (as they arise on my machine) and worked on the ant scripts. I think it's a straight run now for Frank to build and publish. > > The process is here: https://jython-devguide.readthedocs.io/en/latest/release_jy.html When I build and upload I'll see if these docs need updating. > > I have bumped Jython up to Java 8. This broke a few things, now resolved. JarJar does not translate the later bytecode in the version we had used. (See issue 2806.) And Java 8 is picky about Javadoc, where apparently we've not been good :o(. I fixed over a hundred javadoc errors, but I'm leaving the warnings for a later burst of enthusiasm. > > A lot of bugs are fixed in this release and some features added as noted in NEWS. I still have misgivings around the number of suppressed tests (and so many places we can do it), and the way tests involving networking (SSL and Netty) contiunue to be flakey. The socket-related modules are an awesome achievement, but incomplete in some ways. However, one must not let the defects dominate one's thinking. So much is good and improved in 2.7.2, and this includes all the issues we prioritised in the triage. > This is great news! > What do others think? Tag it? Yes, tag it! I agree with Jim that this should be tagged as a beta release. I confirmed that my sonatype login still works, I'm happy to test out the release process and get this published. While I'm there I'll poke around to see if I can find out how new users are added. > Jeff > > -- > Jeff Allen |
|
From: Jim B. <jim...@py...> - 2019-10-06 17:15:10
|
Jeff, I'm glad to hear this great news! We should proceed now as you suggest, given that you have reached the far as you can tell point in the testing process. So let's use this beta to shake out the release process. At this point in this release cycle, our code quality and corresponding testing is very good, so it should not be considered an alpha. Future releases can build further and also provide more assurance on shrinking the time to subsequent releases. Gradle support is a good example here. One nit: there's still an obsolete reference to Java 7 in https://jython-devguide.readthedocs.io/en/latest/release_jy.html : "At the time of writing we target Java 7." - Jim On Sun, Oct 6, 2019 at 2:57 AM Jeff Allen <ja...@fa...> wrote: > I think the version of Jython now at the repo tip is, apart from changing > the metadata, a viable Jython 2.7.2 beta. > > I have dry run the process several times to the point where I can make the > artefacts that would go to Sonatype, at least as far as I can test that. I > have ironed out the problems (as they arise on my machine) and worked on > the ant scripts. I think it's a straight run now for Frank to build and > publish. > > The process is here: > https://jython-devguide.readthedocs.io/en/latest/release_jy.html > > I have bumped Jython up to Java 8. This broke a few things, now resolved. > JarJar does not translate the later bytecode in the version we had used. > (See issue 2806.) And Java 8 is picky about Javadoc, where apparently we've > not been good :o(. I fixed over a hundred javadoc errors, but I'm leaving > the warnings for a later burst of enthusiasm. > > A lot of bugs are fixed in this release and some features added as noted > in NEWS. I still have misgivings around the number of suppressed tests (and > so many places we can do it), and the way tests involving networking (SSL > and Netty) contiunue to be flakey. The socket-related modules are an > awesome achievement, but incomplete in some ways. However, one must not let > the defects dominate one's thinking. So much is good and improved in 2.7.2, > and this includes all the issues we prioritised in the triage. > > What do others think? Tag it? > > Jeff > > -- > Jeff Allen > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Jeff A. <ja...@fa...> - 2019-10-06 09:56:30
|
I think the version of Jython now at the repo tip is, apart from changing the metadata, a viable Jython 2.7.2 beta. I have dry run the process several times to the point where I can make the artefacts that would go to Sonatype, at least as far as I can test that. I have ironed out the problems (as they arise on my machine) and worked on the ant scripts. I think it's a straight run now for Frank to build and publish. The process is here: https://jython-devguide.readthedocs.io/en/latest/release_jy.html I have bumped Jython up to Java 8. This broke a few things, now resolved. JarJar does not translate the later bytecode in the version we had used. (See issue 2806.) And Java 8 is picky about Javadoc, where apparently we've not been good :o(. I fixed over a hundred javadoc errors, but I'm leaving the warnings for a later burst of enthusiasm. A lot of bugs are fixed in this release and some features added as noted in NEWS. I still have misgivings around the number of suppressed tests (and so many places we can do it), and the way tests involving networking (SSL and Netty) contiunue to be flakey. The socket-related modules are an awesome achievement, but incomplete in some ways. However, one must not let the defects dominate one's thinking. So much is good and improved in 2.7.2, and this includes all the issues we prioritised in the triage. What do others think? Tag it? Jeff -- Jeff Allen |
|
From: Jython t. <st...@bu...> - 2019-10-04 18:05:30
|
ACTIVITY SUMMARY (2019-09-27 - 2019-10-04) Jython tracker at https://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 341 ( +3) closed 2445 ( +0) total 2786 ( +3) Open issues with patches: 25 Issues opened (3) ================= #2806: Installer contains dependencies unshaded (Java 8) https://bugs.jython.org/issue2806 opened by jeff.allen #2808: lib2to3 test failures on Windows JDK 11 https://bugs.jython.org/issue2808 opened by adamburke #2810: NoSuchMethodError in test_jython_initializer Java 10+ https://bugs.jython.org/issue2810 opened by adamburke Most recent 15 issues with no replies (15) ========================================== #2804: Missing class com/google/common/base/CharMatcher https://bugs.jython.org/issue2804 #2802: PEP 0263 magic coding comment rejected in UTF-8 https://bugs.jython.org/issue2802 #2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows https://bugs.jython.org/issue2798 #2794: invocation_tests.py missing from modjy tests https://bugs.jython.org/issue2794 #2792: Failures in test_import_jy from Java 13 https://bugs.jython.org/issue2792 #2790: Equivalent signal handlers do not test equal using == https://bugs.jython.org/issue2790 #2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7 https://bugs.jython.org/issue2770 #2760: How to call procedure with use zxjdbc and get back OUT paramet https://bugs.jython.org/issue2760 #2754: Failure in Py.initProxy for class not at module level https://bugs.jython.org/issue2754 #2752: Allow Python functions to be used as a java.lang.FunctionalInt https://bugs.jython.org/issue2752 #2750: Make PyFunction implement java.util.concurrent.Callable<PyObje https://bugs.jython.org/issue2750 #2736: ensurepip fails with: pip 9.0.1 requires SSL/TLS https://bugs.jython.org/issue2736 #2734: Re-work package scanning and cache for modules https://bugs.jython.org/issue2734 #2723: Unusual behavior in SimpleCookie when '=' and '@' is used in https://bugs.jython.org/issue2723 #2722: run-time issue while trying to reach external endpoint (Weathe https://bugs.jython.org/issue2722 Most recent 15 issues waiting for review (15) ============================================= #2566: inspect does not recognize code objects from bytecode files https://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules https://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the https://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses https://bugs.jython.org/issue2367 #2363: relative seeks works incorrectly after readline https://bugs.jython.org/issue2363 #2330: full-build fails to copy CPython License https://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core https://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar https://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context https://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries https://bugs.jython.org/issue2121 #1925: Support loading java.sql.Drivers that aren't on the boot class https://bugs.jython.org/issue1925 #1917: No ctypes.c_char https://bugs.jython.org/issue1917 #1842: Add IBM i support to Jython https://bugs.jython.org/issue1842 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo https://bugs.jython.org/issue1741 #1646: Proxy getInterface not change for more PyObject https://bugs.jython.org/issue1646 |
|
From: Rory O'D. <ror...@or...> - 2019-10-04 09:17:03
|
Hi Alan, *OpenJDK builds *- JDK 14 - Early Access build 17 is available at http://jdk.java.net/14/ These early-access, open-source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Schedule for JDK 14 o 2019/12/12 Rampdown Phase One o 2020/01/16 Rampdown Phase Two o 2020/02/06 Initial Release Candidate o 2020/02/20 Final Release Candidate o 2020/03/17 General Availability * Release notes o https://jdk.java.net/14/release-notes * JEPs targeted to JDK 14, so far o 352 - Non-Volatile Mapped Byte Buffers <https://openjdk.java.net/jeps/352> o 358 - Helpful NullPointerExceptions <http://openjdk.java.net/jeps/358> * Recent Bug fixes of Interest o Build 16:- + JDK-8228580: DnsClient TCP socket timeout + JDK-8229800: WindowsServerCore 1809 does not provide d2d1.dll library required by awt.dll + JDK-8230814: Enable SAX ContentHandler to handle XML Declaration o Build 15:- + JDK-8229202: Docker reporting causes secondary crashes in error handling + JDK-8223490: Optimize search algorithm for determining default time zone * Changes in this build <http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B16%22%3A%3A%22jdk-14%2B17%22-%22jdk-14%2B16%22%29&revcount=1000> *jpackage EA -* Build 14-jpackage+1-49 (2019/10/2) * This is an early access build of JEP 343: Packaging Tool <https://openjdk.java.net/jeps/343>, aimed at testing a prototype implementation of jpackage, which is a new tool for packaging self-contained Java applications along with a Java Runtime Environment. * These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html> * Build 14 is now available http://jdk.java.net/jpackage/ * Please send feedback via e-mail to cor...@op... <mailto:cor...@op...> * * CodeOne * Missed some of the Core Java Platform track, see a thread of some of the captured sessions: here <https://twitter.com/Sharat_Chander/status/1176202284134330368?s=20> Rgds,Rory -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland |
|
From: Jython t. <st...@bu...> - 2019-09-27 18:05:31
|
ACTIVITY SUMMARY (2019-09-20 - 2019-09-27) Jython tracker at https://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 338 ( +1) closed 2445 ( +0) total 2783 ( +1) Open issues with patches: 25 Issues opened (1) ================= #2804: Missing class com/google/common/base/CharMatcher https://bugs.jython.org/issue2804 opened by wfouche2 Most recent 15 issues with no replies (15) ========================================== #2804: Missing class com/google/common/base/CharMatcher https://bugs.jython.org/issue2804 #2802: PEP 0263 magic coding comment rejected in UTF-8 https://bugs.jython.org/issue2802 #2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows https://bugs.jython.org/issue2798 #2794: invocation_tests.py missing from modjy tests https://bugs.jython.org/issue2794 #2792: Failures in test_import_jy from Java 13 https://bugs.jython.org/issue2792 #2790: Equivalent signal handlers do not test equal using == https://bugs.jython.org/issue2790 #2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7 https://bugs.jython.org/issue2770 #2760: How to call procedure with use zxjdbc and get back OUT paramet https://bugs.jython.org/issue2760 #2754: Failure in Py.initProxy for class not at module level https://bugs.jython.org/issue2754 #2752: Allow Python functions to be used as a java.lang.FunctionalInt https://bugs.jython.org/issue2752 #2750: Make PyFunction implement java.util.concurrent.Callable<PyObje https://bugs.jython.org/issue2750 #2736: ensurepip fails with: pip 9.0.1 requires SSL/TLS https://bugs.jython.org/issue2736 #2734: Re-work package scanning and cache for modules https://bugs.jython.org/issue2734 #2723: Unusual behavior in SimpleCookie when '=' and '@' is used in https://bugs.jython.org/issue2723 #2722: run-time issue while trying to reach external endpoint (Weathe https://bugs.jython.org/issue2722 Most recent 15 issues waiting for review (15) ============================================= #2566: inspect does not recognize code objects from bytecode files https://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules https://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the https://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses https://bugs.jython.org/issue2367 #2363: relative seeks works incorrectly after readline https://bugs.jython.org/issue2363 #2330: full-build fails to copy CPython License https://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core https://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar https://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context https://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries https://bugs.jython.org/issue2121 #1925: Support loading java.sql.Drivers that aren't on the boot class https://bugs.jython.org/issue1925 #1917: No ctypes.c_char https://bugs.jython.org/issue1917 #1842: Add IBM i support to Jython https://bugs.jython.org/issue1842 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo https://bugs.jython.org/issue1741 #1646: Proxy getInterface not change for more PyObject https://bugs.jython.org/issue1646 |
|
From: Jython t. <st...@bu...> - 2019-09-20 18:05:31
|
ACTIVITY SUMMARY (2019-09-13 - 2019-09-20) Jython tracker at https://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 337 ( +1) closed 2445 ( +0) total 2782 ( +1) Open issues with patches: 25 Issues opened (1) ================= #2802: PEP 0263 magic coding comment rejected in UTF-8 https://bugs.jython.org/issue2802 opened by rhwood Most recent 15 issues with no replies (15) ========================================== #2802: PEP 0263 magic coding comment rejected in UTF-8 https://bugs.jython.org/issue2802 #2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows https://bugs.jython.org/issue2798 #2794: invocation_tests.py missing from modjy tests https://bugs.jython.org/issue2794 #2792: Failures in test_import_jy from Java 13 https://bugs.jython.org/issue2792 #2790: Equivalent signal handlers do not test equal using == https://bugs.jython.org/issue2790 #2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7 https://bugs.jython.org/issue2770 #2760: How to call procedure with use zxjdbc and get back OUT paramet https://bugs.jython.org/issue2760 #2754: Failure in Py.initProxy for class not at module level https://bugs.jython.org/issue2754 #2752: Allow Python functions to be used as a java.lang.FunctionalInt https://bugs.jython.org/issue2752 #2750: Make PyFunction implement java.util.concurrent.Callable<PyObje https://bugs.jython.org/issue2750 #2736: ensurepip fails with: pip 9.0.1 requires SSL/TLS https://bugs.jython.org/issue2736 #2734: Re-work package scanning and cache for modules https://bugs.jython.org/issue2734 #2723: Unusual behavior in SimpleCookie when '=' and '@' is used in https://bugs.jython.org/issue2723 #2722: run-time issue while trying to reach external endpoint (Weathe https://bugs.jython.org/issue2722 #2720: wrap_scoket_exception: 'module' object has no attribute 'OP_NO https://bugs.jython.org/issue2720 Most recent 15 issues waiting for review (15) ============================================= #2566: inspect does not recognize code objects from bytecode files https://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules https://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the https://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses https://bugs.jython.org/issue2367 #2363: relative seeks works incorrectly after readline https://bugs.jython.org/issue2363 #2330: full-build fails to copy CPython License https://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core https://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar https://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context https://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries https://bugs.jython.org/issue2121 #1925: Support loading java.sql.Drivers that aren't on the boot class https://bugs.jython.org/issue1925 #1917: No ctypes.c_char https://bugs.jython.org/issue1917 #1842: Add IBM i support to Jython https://bugs.jython.org/issue1842 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo https://bugs.jython.org/issue1741 #1646: Proxy getInterface not change for more PyObject https://bugs.jython.org/issue1646 |
|
From: Rory O'D. <ror...@or...> - 2019-09-17 20:24:23
|
Hi Alan,
*Release Announcement: General Availability of Java 13 / JDK 13 [1] *
* JDK 13, the reference implementation of Java 13, is now Generally
Available.
* GPL-licensed OpenJDK builds from Oracle are available here:
https://jdk.java.net/13
* Release notes - https://jdk.java.net/13/release-notes
This release includes the following five features:
* 350: Dynamic CDS Archives
* 351: ZGC: Uncommit Unused Memory
* 353: Reimplement the Legacy Socket API
* 354: Switch Expressions (Preview)
* 355: Text Blocks (Preview)
Along with many smaller enhancements and bug fixes.
Thanks to everyone who contributed JDK 13, whether by creating features
or enhancements, logging bugs, or downloading and testing the
early-access builds.
*JDK 14 EA build 14, under both the GPL and Oracle EA licenses, is now
available at **http://jdk.java.net/14**.*
* JEPs targeted to JDK 14, so far
o 352 - Non-Volatile Mapped Byte Buffers
<https://openjdk.java.net/jeps/352>
* Release Notes
o https://jdk.java.net/14/release-notes
* Recent Bug fixes of Interest
o Build 14:
+ 8229785: MethodType::fromMethodDescriptorString requires
"getClassLoader" permission
+ 8212117: Classes are now loaded and linked by Class.forName()
+ 8228854: Default ErrorListener No Longer Reports Warnings
and Errors to the Console
* Changes in this build
<https://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B13%22%3A%3A%22jdk-14%2B14%22-%22jdk-14%2B13%22%29&revcount=1000>
[14]
*Quality Report for September 2019 is available*
* https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+September+2019
Rgds,Rory
[1]
https://mail.openjdk.java.net/pipermail/jdk-dev/2019-September/003335.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland
|
|
From: Jython t. <st...@bu...> - 2019-09-13 18:05:30
|
ACTIVITY SUMMARY (2019-09-06 - 2019-09-13) Jython tracker at https://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 336 ( +0) closed 2445 ( +0) total 2781 ( +0) Open issues with patches: 25 Most recent 15 issues with no replies (15) ========================================== #2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows https://bugs.jython.org/issue2798 #2794: invocation_tests.py missing from modjy tests https://bugs.jython.org/issue2794 #2792: Failures in test_import_jy from Java 13 https://bugs.jython.org/issue2792 #2790: Equivalent signal handlers do not test equal using == https://bugs.jython.org/issue2790 #2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7 https://bugs.jython.org/issue2770 #2760: How to call procedure with use zxjdbc and get back OUT paramet https://bugs.jython.org/issue2760 #2754: Failure in Py.initProxy for class not at module level https://bugs.jython.org/issue2754 #2752: Allow Python functions to be used as a java.lang.FunctionalInt https://bugs.jython.org/issue2752 #2750: Make PyFunction implement java.util.concurrent.Callable<PyObje https://bugs.jython.org/issue2750 #2736: ensurepip fails with: pip 9.0.1 requires SSL/TLS https://bugs.jython.org/issue2736 #2734: Re-work package scanning and cache for modules https://bugs.jython.org/issue2734 #2723: Unusual behavior in SimpleCookie when '=' and '@' is used in https://bugs.jython.org/issue2723 #2722: run-time issue while trying to reach external endpoint (Weathe https://bugs.jython.org/issue2722 #2720: wrap_scoket_exception: 'module' object has no attribute 'OP_NO https://bugs.jython.org/issue2720 #2713: Rounding a float field causes test_cpickle to fail https://bugs.jython.org/issue2713 Most recent 15 issues waiting for review (15) ============================================= #2566: inspect does not recognize code objects from bytecode files https://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules https://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the https://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses https://bugs.jython.org/issue2367 #2363: relative seeks works incorrectly after readline https://bugs.jython.org/issue2363 #2330: full-build fails to copy CPython License https://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core https://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar https://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context https://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries https://bugs.jython.org/issue2121 #1925: Support loading java.sql.Drivers that aren't on the boot class https://bugs.jython.org/issue1925 #1917: No ctypes.c_char https://bugs.jython.org/issue1917 #1842: Add IBM i support to Jython https://bugs.jython.org/issue1842 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo https://bugs.jython.org/issue1741 #1646: Proxy getInterface not change for more PyObject https://bugs.jython.org/issue1646 |
|
From: Eero A. <eer...@ik...> - 2019-09-09 08:03:24
|
There is a use case that is related to the JAR split of Jython: Using Jython to create a sandboxed scripting environment. That use case would call for some more fine grained splitting of the Jython implementation. Policy permissions are granted by either by code signature or location https://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html For the sandboxed scripting use case one would probably want to have the Jython class loader in it's own JAR in order to restrict class loading in there only. I understand a lot of more work would still be involved in serving this use case, but you could split this as a reservation, if a new jar layout is being taken into use. Eero Aaltonen On Sun, Sep 8, 2019 at 11:40 PM Jeff Allen <ja...@fa...> wrote: > I've noticed that the "project name" for the Gradle-built JAR cannot be > "jython", because we already publish that (being the fat jar). I propose > therefore to name it "jython-slim", in honour of this thread. > > It's experimental anyway: I don't have much confidence it is correctly > built. I could really do with writing an application with it as a > dependency. (Or others doing so during beta.) > > Jeff Allen > > On 21/05/2019 04:45, Adam Burke wrote: > > Hi Raphail > > > > The dev team are working on a gradle build, one of the outputs of > > which would be a slim jar as you describe. > > > > If you look on jython trunk, there is already an experimental > > build.gradle there. You may be able to use that to build an > > experimental jython-only jar. > > > > It's a complex part of the build, so if you know gradle well, I think > > patches are also welcome. > > > > Cheers > > Adam > > > |
|
From: Jeff A. <ja...@fa...> - 2019-09-08 20:39:40
|
I've noticed that the "project name" for the Gradle-built JAR cannot be "jython", because we already publish that (being the fat jar). I propose therefore to name it "jython-slim", in honour of this thread. It's experimental anyway: I don't have much confidence it is correctly built. I could really do with writing an application with it as a dependency. (Or others doing so during beta.) Jeff Allen On 21/05/2019 04:45, Adam Burke wrote: > Hi Raphail > > The dev team are working on a gradle build, one of the outputs of > which would be a slim jar as you describe. > > If you look on jython trunk, there is already an experimental > build.gradle there. You may be able to use that to build an > experimental jython-only jar. > > It's a complex part of the build, so if you know gradle well, I think > patches are also welcome. > > Cheers > Adam > > On Tue, 21 May 2019 at 00:09, Raphail <raf...@ho... > <mailto:raf...@ho...>> wrote: > > I have several hundreds of python scripts that had been running > with Jython > 2.2.1 until now. > This version consumes so much less space in storage memory than > 2.7, and > when I compared those 2, the first one also consumed less memory on my > server startup (about 8MB less). All in all, I don't want to > perform an > update that no matter how I look at it, has no benefits for my > application > (e.g. my project already contains libraries such as mysql > connector and > such) and I'm forced to either continue with 2.2.1 and its unknown > lifespan > or probably give up Jython and rewrite all my scripts to Java. > > It would be really cool if there was a version that excluded all those > external libraries and such, and was more friendly in terms of > consuming > storage space. > > > > -- > Sent from: http://python.6.x6.nabble.com/jython-dev-f1778516.html > > |
|
From: Jython t. <st...@bu...> - 2019-09-06 18:05:25
|
ACTIVITY SUMMARY (2019-08-30 - 2019-09-06) Jython tracker at https://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 336 ( -1) closed 2445 ( +2) total 2781 ( +1) Open issues with patches: 25 Issues opened (1) ================= #2800: Jython script engine hangs on "genericpath.isfile" during its https://bugs.jython.org/issue2800 opened by fviale Most recent 15 issues with no replies (15) ========================================== #2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows https://bugs.jython.org/issue2798 #2796: Request for oversize arrays not handled in BaseBytes and PyByt https://bugs.jython.org/issue2796 #2794: invocation_tests.py missing from modjy tests https://bugs.jython.org/issue2794 #2792: Failures in test_import_jy from Java 13 https://bugs.jython.org/issue2792 #2790: Equivalent signal handlers do not test equal using == https://bugs.jython.org/issue2790 #2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7 https://bugs.jython.org/issue2770 #2760: How to call procedure with use zxjdbc and get back OUT paramet https://bugs.jython.org/issue2760 #2754: Failure in Py.initProxy for class not at module level https://bugs.jython.org/issue2754 #2752: Allow Python functions to be used as a java.lang.FunctionalInt https://bugs.jython.org/issue2752 #2750: Make PyFunction implement java.util.concurrent.Callable<PyObje https://bugs.jython.org/issue2750 #2736: ensurepip fails with: pip 9.0.1 requires SSL/TLS https://bugs.jython.org/issue2736 #2734: Re-work package scanning and cache for modules https://bugs.jython.org/issue2734 #2723: Unusual behavior in SimpleCookie when '=' and '@' is used in https://bugs.jython.org/issue2723 #2722: run-time issue while trying to reach external endpoint (Weathe https://bugs.jython.org/issue2722 #2720: wrap_scoket_exception: 'module' object has no attribute 'OP_NO https://bugs.jython.org/issue2720 Most recent 15 issues waiting for review (15) ============================================= #2566: inspect does not recognize code objects from bytecode files https://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules https://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the https://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses https://bugs.jython.org/issue2367 #2363: relative seeks works incorrectly after readline https://bugs.jython.org/issue2363 #2330: full-build fails to copy CPython License https://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core https://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar https://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context https://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries https://bugs.jython.org/issue2121 #1925: Support loading java.sql.Drivers that aren't on the boot class https://bugs.jython.org/issue1925 #1917: No ctypes.c_char https://bugs.jython.org/issue1917 #1842: Add IBM i support to Jython https://bugs.jython.org/issue1842 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo https://bugs.jython.org/issue1741 #1646: Proxy getInterface not change for more PyObject https://bugs.jython.org/issue1646 Top 10 most discussed issues (1) ================================ #2800: Jython script engine hangs on "genericpath.isfile" during its https://bugs.jython.org/issue2800 3 msgs |
|
From: Jeff A. <ja...@fa...> - 2019-09-03 06:31:42
|
Good, I'm glad that seems sensible. I think there has to be a 2.7.3 as a target for bug-fixes etc.. For me 2.7.2 as a thing we have to get out to clear space for 3. Separate topic. Jeff Allen On 02/09/2019 23:00, Pekka Klärck wrote: > Jim Baker wrote:: >> +100 >> >> I like this well-considered compromise. Source compatibility with Java 7 ensures it is possible for a self service model if there are users who actually need Java 7. Meanwhile we are able to ensure all of our dependencies are supported, which is key for any release. > +1 > >> This approach also gives an immediate path forward to being on Java 11, the only current LTS option, for a Jython 2.7.3, as well as setting up for Jython 3.x development. > Has there been discussion lately about Jython 2.7.3 vs Jython 3? I'd > personally like to see all efforts concentrated on Jython 3 once > Jython 2.7.2 is out. Python 2 EOL being very near, more and more > projects are dropping Python 2 support and at the same time they drop > Jython support as well. For us Jython support is the primary reason to > support Python 2 still after the EOL, but I cannot see us doing it > past 2020 anymore. > > Cheers, > .peke |
|
From: Pekka K. <pe...@ik...> - 2019-09-02 22:01:14
|
Jim Baker wrote::
>
> +100
>
> I like this well-considered compromise. Source compatibility with Java 7 ensures it is possible for a self service model if there are users who actually need Java 7. Meanwhile we are able to ensure all of our dependencies are supported, which is key for any release.
+1
> This approach also gives an immediate path forward to being on Java 11, the only current LTS option, for a Jython 2.7.3, as well as setting up for Jython 3.x development.
Has there been discussion lately about Jython 2.7.3 vs Jython 3? I'd
personally like to see all efforts concentrated on Jython 3 once
Jython 2.7.2 is out. Python 2 EOL being very near, more and more
projects are dropping Python 2 support and at the same time they drop
Jython support as well. For us Jython support is the primary reason to
support Python 2 still after the EOL, but I cannot see us doing it
past 2020 anymore.
Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org
|
|
From: Jim B. <jim...@py...> - 2019-09-01 14:29:29
|
+100 I like this well-considered compromise. Source compatibility with Java 7 ensures it is possible for a self service model if there are users who actually need Java 7. Meanwhile we are able to ensure all of our dependencies are supported, which is key for any release. This approach also gives an immediate path forward to being on Java 11, the only current LTS option, for a Jython 2.7.3, as well as setting up for Jython 3.x development. - Jim On Sun, Sep 1, 2019 at 4:11 AM Jeff Allen <ja...@fa...> wrote: > It is a fact that we remain source-compatible with Java 7. We test on 7, > 8 and 11 in the CI. > > Java 7 is past EOL, and no-one should really be using it in production, > but a few may still be running Jython on it. (No-one has said they are, > so it's at best a reasonable conjecture.) I have observed test failures > with SSL on Java 7, that disappear on Java 8, since upgrading the BC > jars to satisfy security concerns. > > I propose we compile releases up to 2.7.2 final with Java 8, and for the > Java 8 target. (It really doesn't seem right to compile it with an > unsupported Java 7.) This means the Jython that users download will > require a minimum of Java 8 to run. We support up to Java 11, with > reasonable confidence beyond that. > > But we remain source-compatible with Java 7 up to 2.7.2 final. Then, if > a user really needs a version that runs on Java 7, we can show them how > to build one. I believe it is a matter of defining properties in or > around the Ant build, down-grading the BC JARs if need be, and making a > snapshot installer. It will be an "unofficial" build that we do not > undertake to support, and comes with a number of (additional) known > defects. > > Good compromise? > > Jeff > > Jeff Allen > > On 26/07/2019 21:54, Jeff Allen wrote: > > When the project set out to create Jython 2.7.2, it was reasonable > > still to support Java 7. Now we find ourselves on the verge of a 2.7.2 > > beta release, Java 8 seems the logical minimum. We currently build and > > test on Java 7 but some things would resolve themselves if we could > > move on. We intend to support "before and after Jigsaw" JVMs (say 8 > > and 11). > > > > Straw poll: does anyone amongst our users have a good reason why > > Jython 2.7.2 should run on Java 7? > > > > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Jeff A. <ja...@fa...> - 2019-09-01 10:11:47
|
It is a fact that we remain source-compatible with Java 7. We test on 7, 8 and 11 in the CI. Java 7 is past EOL, and no-one should really be using it in production, but a few may still be running Jython on it. (No-one has said they are, so it's at best a reasonable conjecture.) I have observed test failures with SSL on Java 7, that disappear on Java 8, since upgrading the BC jars to satisfy security concerns. I propose we compile releases up to 2.7.2 final with Java 8, and for the Java 8 target. (It really doesn't seem right to compile it with an unsupported Java 7.) This means the Jython that users download will require a minimum of Java 8 to run. We support up to Java 11, with reasonable confidence beyond that. But we remain source-compatible with Java 7 up to 2.7.2 final. Then, if a user really needs a version that runs on Java 7, we can show them how to build one. I believe it is a matter of defining properties in or around the Ant build, down-grading the BC JARs if need be, and making a snapshot installer. It will be an "unofficial" build that we do not undertake to support, and comes with a number of (additional) known defects. Good compromise? Jeff Jeff Allen On 26/07/2019 21:54, Jeff Allen wrote: > When the project set out to create Jython 2.7.2, it was reasonable > still to support Java 7. Now we find ourselves on the verge of a 2.7.2 > beta release, Java 8 seems the logical minimum. We currently build and > test on Java 7 but some things would resolve themselves if we could > move on. We intend to support "before and after Jigsaw" JVMs (say 8 > and 11). > > Straw poll: does anyone amongst our users have a good reason why > Jython 2.7.2 should run on Java 7? > |
|
From: Jython t. <st...@bu...> - 2019-08-30 18:05:26
|
ACTIVITY SUMMARY (2019-08-23 - 2019-08-30) Jython tracker at https://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 337 ( +2) closed 2443 ( +0) total 2780 ( +2) Open issues with patches: 25 Issues opened (2) ================= #2796: Request for oversize arrays not handled in BaseBytes and PyByt https://bugs.jython.org/issue2796 opened by jeff.allen #2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows https://bugs.jython.org/issue2798 opened by adamburke Most recent 15 issues with no replies (15) ========================================== #2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows https://bugs.jython.org/issue2798 #2796: Request for oversize arrays not handled in BaseBytes and PyByt https://bugs.jython.org/issue2796 #2794: invocation_tests.py missing from modjy tests https://bugs.jython.org/issue2794 #2792: Failures in test_import_jy from Java 13 https://bugs.jython.org/issue2792 #2790: Equivalent signal handlers do not test equal using == https://bugs.jython.org/issue2790 #2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7 https://bugs.jython.org/issue2770 #2760: How to call procedure with use zxjdbc and get back OUT paramet https://bugs.jython.org/issue2760 #2754: Failure in Py.initProxy for class not at module level https://bugs.jython.org/issue2754 #2752: Allow Python functions to be used as a java.lang.FunctionalInt https://bugs.jython.org/issue2752 #2750: Make PyFunction implement java.util.concurrent.Callable<PyObje https://bugs.jython.org/issue2750 #2736: ensurepip fails with: pip 9.0.1 requires SSL/TLS https://bugs.jython.org/issue2736 #2734: Re-work package scanning and cache for modules https://bugs.jython.org/issue2734 #2723: Unusual behavior in SimpleCookie when '=' and '@' is used in https://bugs.jython.org/issue2723 #2722: run-time issue while trying to reach external endpoint (Weathe https://bugs.jython.org/issue2722 #2720: wrap_scoket_exception: 'module' object has no attribute 'OP_NO https://bugs.jython.org/issue2720 Most recent 15 issues waiting for review (15) ============================================= #2566: inspect does not recognize code objects from bytecode files https://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules https://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the https://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses https://bugs.jython.org/issue2367 #2363: relative seeks works incorrectly after readline https://bugs.jython.org/issue2363 #2330: full-build fails to copy CPython License https://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core https://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar https://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context https://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries https://bugs.jython.org/issue2121 #1925: Support loading java.sql.Drivers that aren't on the boot class https://bugs.jython.org/issue1925 #1917: No ctypes.c_char https://bugs.jython.org/issue1917 #1842: Add IBM i support to Jython https://bugs.jython.org/issue1842 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo https://bugs.jython.org/issue1741 #1646: Proxy getInterface not change for more PyObject https://bugs.jython.org/issue1646 |
|
From: <fwi...@gm...> - 2019-08-29 19:58:06
|
I agree with Jim, the bugtest target has not aged well and will not be missed :) On Wed, Aug 28, 2019 at 2:45 PM Jeff Allen <ja...@fa...> wrote: > > Thanks for the quick reply Jim. I'll feel no compunction then about removing further tests if they're more trouble than they're worth. > > And perhaps the rest (and the ant target), although harmless, should be consigned to history. I'm just a bit wary since the release instructions called for it, although this too may be old text. > > I spotted that driver.py and support.py provide for calling jythonc, but I haven't seen it attempted in the surviving test. I didn't know why we dropped jythonc. I've mused (without looking) on how one implements generators, realising you somehow have to achieve a resumable function. > > Jeff Allen > > On 28/08/2019 22:30, Jim Baker wrote: > > I would remove them completely. These tests are largely 18 or so years old, and date to the initial implementation of Jython/JPython. I personally surprised they are still there, but there is always cleanup to be done in such a large project, and we just didn't around to this specific cleaning in the past. > > There is also some testing of JPythonC, which we abandoned 10+ years ago, since it is not possible to implement such key functionality as generators, etc, strictly in Java instead of Java bytecode - at least not without significant performance hits (eg using a Python bytecode approach). > > - Jim > > On Wed, Aug 28, 2019 at 3:19 PM Jeff Allen <ja...@fa...> wrote: >> >> I have not paid any attention to the bugtest ant target but Frank's >> notes on releasing say one should run it. It fails miserably. >> >> The tests fail on Windows, because of the way the command line is >> created in bugtests/support.py, but if I fix that, most pass, but many >> do not, and for what appears at first to be a good reason. >> >> Maybe some of these failures are regressions, but on the whole, the >> problem seems to be with the tests. test235 and test236 need .java files >> missing from bugtests/classes; test321 and quite some others fail >> because the class path does not include dist/javalib/*; yet others are >> more obscure. >> >> There has been a great culls in the past. This changeset >> (https://hg.python.org/jython/rev/f494dce0a7e5) is an example and it >> looks carefully reasoned -- tests are superseded by regrtests. However, >> it accidently blows away some files used by tests it leaves behind. The >> bugtest target can't have run cleanly since that point, which is an odd >> way to leave things. >> >> Do we take these tests seriously? >> >> -- >> Jeff Allen >> >> >> >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
|
From: Jeff A. <ja...@fa...> - 2019-08-28 22:04:48
|
I did a fair amount with the Gradle build, but then got stuck. Gradle has a strong principle of "configuration by convention", which in this contrext means if we lay out our work the Gradle way, then default behaviours will automatically do a lot we want. Our layout is nothing like that. I think I'm stuck because with the layout we have, one has to work hard against Gradle, which means understanding a lot of options and features of the DSL. I concluded that restructuring of the code is a pre-requisite for the transition to Gradle. In that case, the change may be easier as a "big bang", where we stop using Ant abruptly. That or we have to rewrite the Ant build for the new layout so it can continue to be the workhorse. I would have judged the latter impractical a few weeks ago, but have got to know Ant and build.xml quite well lately, putting gradual back as a possibility. Jeff Allen On 20/08/2019 03:54, Adam Burke wrote: > Over time, $0.02 in hand, I would suggest cutting pieces out of the > ant build and moving them into the gradle build. As gradle can invoke > ant, it does not need to be done in one big hit, but can be tackled > task-by-task. Have gone through a similar process in the past with > maven wrapping ant, then finally discontinuing the use of ant after > multiple iterations. > > Eg one starting point could be to make gradle clean the definitive > clean job. > > Can't remember if this was the stated direction in the past, but have > seen it work. > > Cheers > Adam > > On Tue, 20 Aug 2019 at 06:52, Jeff Allen <ja...@fa... > <mailto:ja...@fa...>> wrote: > > Jim: > > Maybe the distinct checkout was necessary with SVN. It doesn't > seem to be now. > > Regarding snapshots, you may find the current tip (just pushed) > interesting as one can now easily make a snapshot installer. We > could (maybe should) label the JAR with the version, but at > present, that's the job of the separate maven/build.xml. > > Also, I finally figured out how branding the README is supposed to > work. :) > > Jeff Allen > > On 19/08/2019 21:38, Jim Baker wrote: >> Jeff, >> >> Your cleanup and observations make sense to me. I don't know the >> exact history, but certain decisions in build.xml were no doubt >> prompted by earlier VCS aspects - at the very least, Jython has >> been on Subversion and Mercurial while I have worked on it, but >> surely it was even earlier on something like CVS. >> >> Looking forward: We can clearly can snapshot the build more >> readily and reduce overhead. Ideally it's built purely in a fresh >> container, etc, as part of an overall CI, but let's not get ahead >> of ourselves, especially given testing realities on Windows, OSX, >> and Linux. >> >> - Jim >> >> On Mon, Aug 19, 2019 at 1:30 AM Jeff Allen <ja...@fa... >> <mailto:ja...@fa...>> wrote: >> >> There are swathes of build.xml I've never really understood. >> Many are >> bits that have to work to make a release (full-build). A lot >> of this is >> good, but somewhat buggy, and it has been "particularised" to >> releases >> in the past, by which I mean what might have been >> general-purpose logic >> has become hard-coding of the answer for that particular >> release, >> presumably to work around some shortcoming in the logic. >> >> It is difficult to debug the full-build target because it >> checks out a >> fresh copy of the repo and works on that. This is slow, and >> in my >> experience frail. It also means that when testing some hacky >> idea, it >> (or parts of it) have to be pushed to the official repo. I >> think this is >> how the particularisations got into the official copy. >> >> So I'm trying the idea of full-build without the checkout. >> It's quite a >> big change to build.xml. Building a release from the >> directory where you >> do development is a bad idea, I know, because there are >> always extra >> files lying around that can get incorporated, or might be >> necessary to >> make it work, but you didn't check in. For the same reason, >> it is good >> routinely to have an integration workspace to which you pull >> before you >> push: with git it is a topic branch of your personal repo. >> >> I think that for a release, one would always check out to a >> clean >> workspace, so it is not necessary to have the script do it. I >> have >> incorporated tests to warn us when it is not clean (hg >> status, etc.), >> and then one can only build a "SNAPSHOT". Apart from these >> tests, the >> whole script gets somewhat simpler. Or maybe I just >> understand it better. >> >> I may have missed an important reason why we did the checkout >> elsewhere: >> do say if you know it. >> >> As always, this is turning up lots of things I never knew or >> noticed. >> E.g. have you noticed "ant clean" doesn't do a complete job >> these days? >> Not for me, anyway. I'm left with some editor droppings that >> have >> accumulated in my build/dist directories. They prevent a >> complete clean >> because of >> https://ant.apache.org/manual/dirtasks.html#defaultexcludes . >> And I have figured out the intended template processing of >> README.txt so >> it need not be kept in sync manually. >> >> I just thought I'd say on the list what I'm up to. >> >> -- >> Jeff Allen >> >> >> >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> <mailto:Jyt...@li...> >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > <mailto:Jyt...@li...> > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Jeff A. <ja...@fa...> - 2019-08-28 21:44:37
|
Thanks for the quick reply Jim. I'll feel no compunction then about removing further tests if they're more trouble than they're worth. And perhaps the rest (and the ant target), although harmless, should be consigned to history. I'm just a bit wary since the release instructions called for it, although this too may be old text. I spotted that driver.py and support.py provide for calling jythonc, but I haven't seen it attempted in the surviving test. I didn't know why we dropped jythonc. I've mused (without looking) on how one implements generators, realising you somehow have to achieve a resumable function. Jeff Allen On 28/08/2019 22:30, Jim Baker wrote: > I would remove them completely. These tests are largely 18 or so years > old, and date to the initial implementation of Jython/JPython. I > personally surprised they are still there, but there is always cleanup > to be done in such a large project, and we just didn't around to this > specific cleaning in the past. > > There is also some testing of JPythonC, which we abandoned 10+ years > ago, since it is not possible to implement such key functionality as > generators, etc, strictly in Java instead of Java bytecode - at least > not without significant performance hits (eg using a Python bytecode > approach). > > - Jim > > On Wed, Aug 28, 2019 at 3:19 PM Jeff Allen <ja...@fa... > <mailto:ja...@fa...>> wrote: > > I have not paid any attention to the bugtest ant target but Frank's > notes on releasing say one should run it. It fails miserably. > > The tests fail on Windows, because of the way the command line is > created in bugtests/support.py, but if I fix that, most pass, but > many > do not, and for what appears at first to be a good reason. > > Maybe some of these failures are regressions, but on the whole, the > problem seems to be with the tests. test235 and test236 need .java > files > missing from bugtests/classes; test321 and quite some others fail > because the class path does not include dist/javalib/*; yet others > are > more obscure. > > There has been a great culls in the past. This changeset > (https://hg.python.org/jython/rev/f494dce0a7e5) is an example and it > looks carefully reasoned -- tests are superseded by regrtests. > However, > it accidently blows away some files used by tests it leaves > behind. The > bugtest target can't have run cleanly since that point, which is > an odd > way to leave things. > > Do we take these tests seriously? > > -- > Jeff Allen > > > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > <mailto:Jyt...@li...> > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Jim B. <jim...@py...> - 2019-08-28 21:30:52
|
I would remove them completely. These tests are largely 18 or so years old, and date to the initial implementation of Jython/JPython. I personally surprised they are still there, but there is always cleanup to be done in such a large project, and we just didn't around to this specific cleaning in the past. There is also some testing of JPythonC, which we abandoned 10+ years ago, since it is not possible to implement such key functionality as generators, etc, strictly in Java instead of Java bytecode - at least not without significant performance hits (eg using a Python bytecode approach). - Jim On Wed, Aug 28, 2019 at 3:19 PM Jeff Allen <ja...@fa...> wrote: > I have not paid any attention to the bugtest ant target but Frank's > notes on releasing say one should run it. It fails miserably. > > The tests fail on Windows, because of the way the command line is > created in bugtests/support.py, but if I fix that, most pass, but many > do not, and for what appears at first to be a good reason. > > Maybe some of these failures are regressions, but on the whole, the > problem seems to be with the tests. test235 and test236 need .java files > missing from bugtests/classes; test321 and quite some others fail > because the class path does not include dist/javalib/*; yet others are > more obscure. > > There has been a great culls in the past. This changeset > (https://hg.python.org/jython/rev/f494dce0a7e5) is an example and it > looks carefully reasoned -- tests are superseded by regrtests. However, > it accidently blows away some files used by tests it leaves behind. The > bugtest target can't have run cleanly since that point, which is an odd > way to leave things. > > Do we take these tests seriously? > > -- > Jeff Allen > > > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Jeff A. <ja...@fa...> - 2019-08-28 21:19:08
|
I have not paid any attention to the bugtest ant target but Frank's notes on releasing say one should run it. It fails miserably. The tests fail on Windows, because of the way the command line is created in bugtests/support.py, but if I fix that, most pass, but many do not, and for what appears at first to be a good reason. Maybe some of these failures are regressions, but on the whole, the problem seems to be with the tests. test235 and test236 need .java files missing from bugtests/classes; test321 and quite some others fail because the class path does not include dist/javalib/*; yet others are more obscure. There has been a great culls in the past. This changeset (https://hg.python.org/jython/rev/f494dce0a7e5) is an example and it looks carefully reasoned -- tests are superseded by regrtests. However, it accidently blows away some files used by tests it leaves behind. The bugtest target can't have run cleanly since that point, which is an odd way to leave things. Do we take these tests seriously? -- Jeff Allen |
101 messages has been excluded from this view by a project administrator.
