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: Rory O'D. <ror...@or...> - 2019-08-24 16:36:53
|
Hi Alan,
*JDK 13 is now in the Release Candidate Phase
*
Per the JDK 13 schedule [1], we are now in the Release Candidate phase.
The stabilization repository, jdk/jdk13, is open for P1 bug fixes per
the JDK Release Process (JEP 3) [2].
All changes require approval via the Fix-Request Process [3].
For more details, see Mark Reinhold's email to jdk-dev mailing list [4]
* Milestone Schedule:
o GAC - Aug 22, 2019
o GAR - Sept 5, 2019
o GA - Sept 17, 2019
**OpenJDK 14 *EA build 11 is now 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>.
* Release Notes
o http://jdk.java.net/14/release-notes
* JEPs targeted to JDK 14
o JEP 352 <http://openjdk.java.net/jeps/352> - Non-Volatile Mapped
Byte Buffers
* Significant changes since the last availability email:
o Build 10
+ 8226374: Restrict TLS signature schemes and named groups
+ 8227439: Turn off AOT by default
o Build 11
+ 8224974: Implement JEP 352
* Changes in this build
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B10%22%3A%3A%22jdk-14%2B11%22-%22jdk-14%2B10%22%29&revcount=1000>
*jpackage EA - **Build 1 (2019/8/20) *
* 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.
* Build 1 (2019/8/20) is now available http://jdk.java.net/jpackage/
* Please send feedback via e-mail to cor...@op...
<mailto:cor...@op...>
Regards,
Rory
[1] https://openjdk.java.net/projects/jdk/13/#Schedule
[2] https://openjdk.java.net/jeps/3
[3] https://openjdk.java.net/jeps/3#Fix-Request-Process
[4] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-August/003250.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
|
|
From: Jython t. <st...@bu...> - 2019-08-23 18:05:24
|
ACTIVITY SUMMARY (2019-08-16 - 2019-08-23) 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 335 ( -1) closed 2443 ( +1) total 2778 ( +0) Open issues with patches: 25 Most recent 15 issues with no replies (15) ========================================== #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 #2698: urllib2.URLError: <urlopen error unknown url type: https> https://bugs.jython.org/issue2698 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 Issues closed (1) ================= #2658: Update jython.org website https://bugs.jython.org/issue2658 closed by jamesmudd |
|
From: Jeff A. <ja...@fa...> - 2019-08-21 19:09:25
|
Oti: Nice to hear from you as I know your prints are on this from way back. As I understand it, -Dhas.repositories.connection=false would let me use the checked-out copy from an initial full-build. I think that does still work, in itself, but a few other things don't, and I find them hard to debug in that configuration. I'm pursuing the idea that the build should occur in normal checkout directory: a fresh one, not where I've previously done development. I tend to do these from a local, never-modified, clone of hg.python.org/jython, to spare the upstream server and for reliability. Being clear in the instructions that a build properly for release must be from fresh, and putting in some simple safeguards, will control the risk of building from a polluted state (is the idea I'm testing). Meanwhile I can hack at it and run full-build as much as I like, breaking the above rule (making only snapshot installers), knowing that I'm testing the release process we eventually use when building seriously. I only see a few small obstacles (e.g. the checked-out README.txt is modified in situ) and I know what to do about them. Jeff Allen On 21/08/2019 06:34, Oti wrote: > Hi Jeff > > I think you are completely right that checking out makes only sense > for doing a release full build. > If you want a full build from your local sources, without a checkout, > you can define > > > # - set this to false if you want the full build run from the checked > out sources > > has.repositories.connection=false > > > in the file 'ant.properties' just beside 'build.xml'. > > Thats the way I always did it. > I hope this still works for you. > > Best wishes, > Oti. > > On Mon, Aug 19, 2019 at 9:31 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 > > > > -- > http://ohumbel.me |
|
From: Oti <oh...@gm...> - 2019-08-21 05:34:53
|
Hi Jeff I think you are completely right that checking out makes only sense for doing a release full build. If you want a full build from your local sources, without a checkout, you can define # - set this to false if you want the full build run from the checked out sources has.repositories.connection=false in the file 'ant.properties' just beside 'build.xml'. Thats the way I always did it. I hope this still works for you. Best wishes, Oti. On Mon, Aug 19, 2019 at 9:31 AM Jeff Allen <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... > https://lists.sourceforge.net/lists/listinfo/jython-dev > -- http://ohumbel.me |
|
From: <fwi...@gm...> - 2019-08-20 21:21:12
|
On Mon, Aug 19, 2019 at 7:55 PM Adam Burke <ada...@gm...> 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. I'm also all for this approach, it would be nice to slowly move to gradle. -Frank |
|
From: <fwi...@gm...> - 2019-08-20 21:19:01
|
On Mon, Aug 19, 2019 at 2:06 PM Jim Baker <jim...@py...> 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. > FWIW I can confirm that it was on CVS, one of my earliest contributions was helping to move to SVN. -Frank |
|
From: Jim B. <jim...@py...> - 2019-08-20 04:19:50
|
Adam, agreed with this approach. I had hoped we would do it for 2.7.2 but clearly I was too ambitious given the time I had available! On Mon, Aug 19, 2019, 8:54 PM Adam Burke <ada...@gm...> 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...> 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...> 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... >>> https://lists.sourceforge.net/lists/listinfo/jython-dev >>> >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> > |
|
From: Adam B. <ada...@gm...> - 2019-08-20 02:55:01
|
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...> 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...> 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... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Jim B. <jim...@py...> - 2019-08-19 21:05:47
|
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...> 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... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Jeff A. <ja...@fa...> - 2019-08-19 20:51:50
|
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 > |
|
From: Jeff A. <ja...@fa...> - 2019-08-19 07:30:40
|
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 |
|
From: Jython t. <st...@bu...> - 2019-08-16 18:20:56
|
ACTIVITY SUMMARY (2019-08-09 - 2019-08-16) 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 2442 ( +0) total 2778 ( +1) Open issues with patches: 25 Issues opened (1) ================= #2794: invocation_tests.py missing from modjy tests https://bugs.jython.org/issue2794 opened by jeff.allen Most recent 15 issues with no replies (15) ========================================== #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 #2698: urllib2.URLError: <urlopen error unknown url type: https> https://bugs.jython.org/issue2698 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: Jeff A. <ja...@fa...> - 2019-08-13 05:43:52
|
Hi Alan: I hoped you would still be watching the list. Thanks for responding. It's a long time since this change set: if you don't have the right file, maybe you can guess what ought to be in it. (I can't. Releasing Jython is taking me places I've steadfastly ignored.) Sorry we haven't been testing your work. I've pushed two changes: one restores the tests to run (but fail), and a second that comments out just the failing tests, so it is easily reverted. I've raised https://bugs.jython.org/issue2794 to remind us to fix it (if we can) and explain the commenting out. "ant test" is now a really thorough test (approaching one hour on my machine). We really must make Jython faster. Jeff Allen On 12/08/2019 15:37, Alan Kennedy wrote: > Thanks for pointing it out Jeff, I'll look into this week. > > I'm pretty sure that moody is in use by lots of folks, so we should > definitely be running and passing all tests. > > Alan. > > > On Sun, Aug 11, 2019 at 8:52 PM Jeff Allen <ja...@fa... > <mailto:ja...@fa...>> wrote: > > I'm dry-running the steps to make a release. The instructions say > "run all the tests" and "ant test" seems to do that, so I've been > trying to make it work. I've restored a missing JAR, and right now > there seems only to be one failure. > > ~/tests/modjy/java/com/xhaus/ModjyTestAppInvocation.java is > looking for ~/tests/modjy/test_apps_dir/invocation_tests.py but it > has never existed in our codebase. Presumably, it was overlooked > at check it in. Definitely, we have not run these tests > successfully since https://hg.python.org/jython/rev/76f8e597de04 . > > I'm reluctant to remove the tests that need it if it might be > around somewhere. Anyone know? > > -- > Jeff Allen > > > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
|
From: Alan K. <jyt...@xh...> - 2019-08-12 14:38:05
|
Thanks for pointing it out Jeff, I'll look into this week. I'm pretty sure that moody is in use by lots of folks, so we should definitely be running and passing all tests. Alan. On Sun, Aug 11, 2019 at 8:52 PM Jeff Allen <ja...@fa...> wrote: > I'm dry-running the steps to make a release. The instructions say "run all > the tests" and "ant test" seems to do that, so I've been trying to make it > work. I've restored a missing JAR, and right now there seems only to be one > failure. > > ~/tests/modjy/java/com/xhaus/ModjyTestAppInvocation.java is looking for > ~/tests/modjy/test_apps_dir/invocation_tests.py but it has never existed > in our codebase. Presumably, it was overlooked at check it in. Definitely, > we have not run these tests successfully since > https://hg.python.org/jython/rev/76f8e597de04 . > > I'm reluctant to remove the tests that need it if it might be around > somewhere. Anyone know? > > -- > Jeff Allen > > |
|
From: Jeff A. <ja...@fa...> - 2019-08-11 19:52:38
|
I'm dry-running the steps to make a release. The instructions say "run all the tests" and "ant test" seems to do that, so I've been trying to make it work. I've restored a missing JAR, and right now there seems only to be one failure. ~/tests/modjy/java/com/xhaus/ModjyTestAppInvocation.java is looking for ~/tests/modjy/test_apps_dir/invocation_tests.py but it has never existed in our codebase. Presumably, it was overlooked at check it in. Definitely, we have not run these tests successfully since https://hg.python.org/jython/rev/76f8e597de04 . I'm reluctant to remove the tests that need it if it might be around somewhere. Anyone know? -- Jeff Allen |
|
From: Rory O'D. <ror...@or...> - 2019-08-10 10:18:14
|
Hi Alan,
*JDK 13 is now in the Release Candidate Phase - if you are aware of any
issues, please let us know.
*
Per the JDK 13 schedule [1], we are now in the Release Candidate phase.
The stabilization repository, jdk/jdk13, is open for P1 bug fixes per
the JDK Release Process (JEP 3) [2].
All changes require approval via the Fix-Request Process [3].
For more details, see Mark Reinhold's email to jdk-dev mailing list [4]
* Milestone Schedule:
o Initial RC Build 33 - Aug 9, 2019
o GAC - Aug 22, 2019
o GAR - Sept 5, 2019
o GA - Sept 17, 2019
*OpenJDK 13 build 33 is available at http://jdk.java.net/13/*
* 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, status & features
o http://openjdk.java.net/projects/jdk/13/
* Release Notes
o http://jdk.java.net/13/release-notes
* Bug fixes reported by Open Source Projects :
o JDK-8228764 - fixed in b32 -reported by Apache Tomcat
**OpenJDK 14 *EA build 9 is now 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>.
* Release Notes
o http://jdk.java.net/14/release-notes
* JEPs targeted to JDK 14
o JEP 352 <http://openjdk.java.net/jeps/352> - Non-Volatile Mapped
Byte Buffers
* Changes in this build
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-14%2B8%22%3A%3A%22jdk-14%2B9%22-%22jdk-14%2B8%22%29&revcount=1000>
* Bug fixes reported by Open Source Projects :
o JDK-8227170 - fixed in b8 -reported by Apache Ant
o JDK-8228485 - fixed in b8 -reported by JaCoCo
o JDK-8222791 - fixed in b7 -reported by Apache Lucene
*Project Panama Early-Access Builds*
* Build jdk-14-panama+1-15 (2019/8/8) is available at
http://jdk.java.net/panama/
* 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>.
Regards,
Rory
[1] https://openjdk.java.net/projects/jdk/13/#Schedule
[2] https://openjdk.java.net/jeps/3
[3] https://openjdk.java.net/jeps/3#Fix-Request-Process
[4] https://mail.openjdk.java.net/pipermail/jdk-dev/2019-August/003250.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
|
|
From: Jeff A. <ja...@fa...> - 2019-08-10 06:49:06
|
On 27/07/2019 17:32, James Klo via Jython-users wrote: > [snipped lots of other good points] > > Jeff mentions: >> >> We currently build and test >> on Java 7 but some things would resolve themselves if we >> could move on. >> > > Could there be some elaboration here? What issues on the 2.7.2 > milestone would be solved by moving to J8? Pluses and minuses here > would be helpful. I was thinking of: * https://bugs.jython.org/issue2770 (SSL test failures) * I wrote a substitute base64 decoder in https://bugs.jython.org/issue2663 (which was fun, but it could be removed at Java 8). * The odd place where a lambda would save nugatory work (logging). Only the first is an actual problem for users (who have to downgrade their JAR to match their insecure JVM). There may be other bugs we didn't consider blockers that are also 7-isms. Jeff Jeff Allen |
|
From: Jython t. <st...@bu...> - 2019-08-09 18:05:24
|
ACTIVITY SUMMARY (2019-08-02 - 2019-08-09) 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 335 ( +1) closed 2442 ( +0) total 2777 ( +1) Open issues with patches: 25 Issues opened (1) ================= #2792: Failures in test_import_jy from Java 13 https://bugs.jython.org/issue2792 opened by jeff.allen Most recent 15 issues with no replies (15) ========================================== #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 #2698: urllib2.URLError: <urlopen error unknown url type: https> https://bugs.jython.org/issue2698 #2697: name$py.class is ignored when in a JAR with name.py https://bugs.jython.org/issue2697 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) ================================ #2778: Use Java logging framework https://bugs.jython.org/issue2778 3 msgs |
|
From: Jython t. <st...@bu...> - 2019-08-02 18:05:24
|
ACTIVITY SUMMARY (2019-07-26 - 2019-08-02) 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 334 ( +1) closed 2442 ( +0) total 2776 ( +1) Open issues with patches: 25 Issues opened (1) ================= #2790: Equivalent signal handlers do not test equal using == https://bugs.jython.org/issue2790 opened by jeff.allen Most recent 15 issues with no replies (15) ========================================== #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 #2698: urllib2.URLError: <urlopen error unknown url type: https> https://bugs.jython.org/issue2698 #2697: name$py.class is ignored when in a JAR with name.py https://bugs.jython.org/issue2697 #2684: WindowsError:[Error 123] The filename,directory name,or volume https://bugs.jython.org/issue2684 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: Stefan R. <ste...@gm...> - 2019-07-27 18:52:03
|
> Are we talking weeks or or over a year away from a release? On Jython-dev mailing list, Jeff recently started a thread about Jython 2.7.2 beta phase details. So I assumed in my vote that the release is reasonably close. I agree that supporting Java 7 does not make sense if that's not the case. I also assumed that Jython 2.7.2 would be forward compatible as work went into supporting Java 9+. It runs well also on Java 8 right now. And if not in some aspects, I doubt that it would do much good just to say "J7 is not supported any more" without doing actual changes beyond stopping building and testing on J7. Actually and significantly leveraging Java 8 advantages requires additional work and wouldn't be feasible for a soonish release. Better cut here (like it was the plan) and do a proper Java 8(+?) integration for 2.7.3 and/or 3. > ...seems more important that trying to support people who decided not to upgrade 3-4 years ago from J7. I also agree here. My point was not to support them; just not to "intentionally" hurt them without compelling reason. Regarding the elephant - I'll postpone that topic for now. Am Sa., 27. Juli 2019 um 18:32 Uhr schrieb James Klo <ji...@sr...>: > This seems to be the most credible argument for not changing to J8 for > 2.7.2. > > However lets unpack that a bit. > > Dropping Java 7 support just "one second" before 2.7.2 release looks > rushed to me. > > > While I agree in theory - “one second” in Jython time appears to be in the > year range given the amount of resources that I have observed to supporting > advancement of the project. Are we talking weeks or or over a year away > from a release? If latter I think in the best interests of both the current > and future community that would like to utilize 2.7.2 - J8 is a better > choice. That opens the door wider community wanting to incorporate. For us, > we’ve had to stifle development on a custom lexer library that we access > via pygments in order to retain Jython support. If we’re saying a release > is eminent within a few weeks to a month I say just wrap up with J7, and > the next version makes J8 the minimum. But Jython is quickly advancing into > irrelevance as fewer and fewer projects are left that will work with J7. > Modern projects won’t want to refactor libraries backwards just to gain > Jython support - they’ll start looking for alternatives that are more > modern. > > I personally know a company where still Java 6 is floating around and I > suspect there are plenty. So the EOL argument > is more a virtual one. > > > OpenJDK is where the world is at in the post-apocalyptic world known as > Oracle Java. Those companies that have chosen to stick with 6 (and even 7 > at this point) have concluded that they have the resources to support their > back porting modern frameworks to fit their circumstances. I hate sounding > like a dick, but given the number of developer resources available to > support the Jython project - that already moves at a snails pace - growing > adoption and the developer community around a solution that a wider > audience can use seems more important that trying to support people who > decided not to upgrade 3-4 years ago from J7. > > Jeff mentions: > > We currently build and test >>> on Java 7 but some things would resolve themselves if we could move on. >> >> > Could there be some elaboration here? What issues on the 2.7.2 milestone > would be solved by moving to J8? Pluses and minuses here would be helpful. > > The other elephant in the room is certainly around Python 3. The looming > end of life for Python 2 is fast approaching. While I concede this isn’t > necessarily a problem for Jython but it does define what a final 2.7.x > features would need to be supported. How long does this project intend to > support the Python 2.7 language spec? When do we support Python 3? I’m > already seeing a fair number of modules not being supported for Python 2. > The last time I had to build our runtime environment I had to go and pull > package dependencies from sources as I could no longer download compatible > versions for Jython. With the vast majority of new Python scripting > happening around Python 3 - this is only going to get worse Furthering J7 > much longer furthers an ecosystem of frameworks that is all but obsolete > and difficult to incorporate into modern projects. > > My vote. If 2.7.2 is close to release (meaning days to weeks) stick to J7 > for the sake of getting it done. If we’re talking more than a month or more > - I vote J8 as IMO throws out a lifeline for the Jython project as a whole. > > - jk > > |
|
From: Stefan R. <ste...@gm...> - 2019-07-27 12:02:12
|
AFAIK, the current Jython 2.7 master still compiles and runs with Java 7. So why would we drop that support right now? At least I think we shouldn't explicitly/on purpose destroy Java 7 compatibility e.g. by inserting a lambda or so somewhere. Dropping Java 7 support just "one second" before 2.7.2 release looks rushed to me. IMO the right moment to drop support for something is right after a release not in the last moment before a release. It's usually good practice to have a designated last release to support something. For 2.7.2 it was decided some time ago that it would be that last release to support Java 7 IIRC. I personally know a company where still Java 6 is floating around and I suspect there are plenty. So the EOL argument is more a virtual one. Anyway, I'm not fanatic for Java 7, it just appears to be a low-hanging fruit to keep the compatibility just on these last meters till the release. And all the named reasons sum up for me to vote for Java 7 support in 2.7.2. At least, let's make Java 7 support "on best effort", i.e. avoid to break it explicitly, and Java 8 can be the official support. That's my view. Best Stefan Am Sa., 27. Juli 2019 um 01:48 Uhr schrieb Jim Baker <jim...@py...>: > Previously we resolved this issue based on what version of Java is > publicly and currently supported. Given Java 7 was end of lifed a few years > ago, and these problems, it makes sense to require Java 8 (or 11, for > similar reasons). > > On Fri, Jul 26, 2019, 1:54 PM Jeff Allen <ja...@fa...> 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? >> >> -- >> Jeff Allen >> >> >> >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> > _______________________________________________ > Jython-users mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-users > |
|
From: Jim B. <jim...@py...> - 2019-07-26 23:58:34
|
Agreed with a quick beta. There has been significant progress here, it's time to finalize this release. On Thu, Jul 25, 2019, 8:29 PM Adam Burke <ada...@gm...> wrote: > It would be great to get 2.7.2b out. > > I made some more progress on locale after I had to put it down for a > while. Hope to have the next patch out soon, but I agree it should not be a > blocker. > > I think it makes sense to drop Java 7 support. Would you drop immediately, > or announce now that it will be dropped in 2.7.3? > > My $0.02 on duration is a month of beta is heaps now people are used to > higher frequency releases of software generally. > > Adam > > > 在 2019年7月26日，上午7:08，Jeff Allen <ja...@fa...> 写道： > > > > The list we made in 2018 of bugs essential to fix for 2.7.2 < > https://bugs.jython.org/issue?@columns=title,id,activity,status&@sort=-activity&@group=priority&@filter=status,milestone&@pagesize=50&@startwith=0&status=1&milestone=4&@dispname=Milestone%202.7.2>, > despite adding new ones that looked like we ought to, and those where > somebody just fancied doing it, is now almost empty. The ones left open > relate to: > > > > 1. The website, where James has done a great job with GithHub and we > > just need to get jython.org pointed at it. (#2658, #1590) > > 2. Gradle, where I've done all I know how to, and would like user > > experience to tell us what is lacking. (#2121, #2182) > > > > Two more things would be nice to have, but I don't count them as > blockers: > > > > 1. Adam's partial implementation of locale. (GH-132 > > <https://github.com/jythontools/jython/pull/132>) > > 2. Adopt standard Java logging. (#2278, #2778 > > <https://bugs.jython.org/issue2778>) > > > > Bottom line: I think we might be ready to release a beta. > > > > I think it possible to add locale during it, as it is "opt-in", but > would rather find a bug now than in 2.7.3. > > > > A few proper bugs remain "pending" that were on the 2.7.2 list, simply > waiting to close, except (#2230 <https://bugs.jython.org/issue2230>) > where I would like have the feeedback that gives me the confidence to close > it, from an environment that exercises it properly. A few questions: > > > > Am I missing anything? > > > > Should we drop support for Java 7 at this point? (18 months ago, > maintaining support was sensible, but this has taken a year longer than > intended.) > > > > How long from beta to rc1 (if all is well)? > > > > Jeff > > > > 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: Jim B. <jim...@py...> - 2019-07-26 23:49:14
|
Previously we resolved this issue based on what version of Java is publicly and currently supported. Given Java 7 was end of lifed a few years ago, and these problems, it makes sense to require Java 8 (or 11, for similar reasons). On Fri, Jul 26, 2019, 1:54 PM Jeff Allen <ja...@fa...> 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? > > -- > Jeff Allen > > > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Jeff A. <ja...@fa...> - 2019-07-26 20:54:38
|
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? -- Jeff Allen |
|
From: Jython t. <st...@bu...> - 2019-07-26 18:05:23
|
ACTIVITY SUMMARY (2019-07-19 - 2019-07-26) 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 333 (-12) closed 2442 (+12) total 2775 ( +0) Open issues with patches: 25 Most recent 15 issues with no replies (15) ========================================== #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 #2698: urllib2.URLError: <urlopen error unknown url type: https> https://bugs.jython.org/issue2698 #2697: name$py.class is ignored when in a JAR with name.py https://bugs.jython.org/issue2697 #2684: WindowsError:[Error 123] The filename,directory name,or volume https://bugs.jython.org/issue2684 #2680: Ignore Java accessibility rules selectively by package (Java 9 https://bugs.jython.org/issue2680 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) ================================ #2345: Installing pip fails if JYTHON_HOME set and points to old inst https://bugs.jython.org/issue2345 3 msgs |
101 messages has been excluded from this view by a project administrator.
