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: Jython t. <st...@bu...> - 2018-01-05 17:10:23
|
ACTIVITY SUMMARY (2017-12-29 - 2018-01-05) Jython tracker at http://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 ( +0) closed 2336 ( +0) total 2670 ( +0) Open issues with patches: 29 Most recent 15 issues with no replies (15) ========================================== #2651: Travis Builds failing with *** buffer overflow detected *** http://bugs.jython.org/issue2651 #2648: Show report on screen with Python and JasperReport http://bugs.jython.org/issue2648 #2645: pop method returns wrong result with Java LinkedList http://bugs.jython.org/issue2645 #2644: Representation of Java maps with String keys differs from Pyth http://bugs.jython.org/issue2644 #2642: ImportError when importing in multiple PyScriptEngine concurre http://bugs.jython.org/issue2642 #2640: Virtualenv gets confused using paths with ~ http://bugs.jython.org/issue2640 #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2633: Unicode garbled in writing to spreadsheet via openpyxl http://bugs.jython.org/issue2633 #2631: jython 2.7.1 [Errno 107] Socket is not connected http://bugs.jython.org/issue2631 #2618: socket.sendall no longer sends all http://bugs.jython.org/issue2618 #2616: Incomplete / broken support for Certificate Revocation Lists http://bugs.jython.org/issue2616 #2613: 2.7.1 MANIFEST.MF contains unfilled placeholders http://bugs.jython.org/issue2613 #2611: mkdir() operation in /Lib/os.py has different behavior when ru http://bugs.jython.org/issue2611 #2606: jython launch problem sun.misc.InvalidJarIndexException http://bugs.jython.org/issue2606 #2605: Jython 2.7.0 startup performance regression http://bugs.jython.org/issue2605 Most recent 15 issues waiting for review (15) ============================================= #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2566: inspect does not recognize code objects from bytecode files http://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules http://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the http://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses http://bugs.jython.org/issue2367 #2330: full-build fails to copy CPython License http://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core http://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar http://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context http://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries http://bugs.jython.org/issue2121 #2077: marshal doesn't raise error when fed unmarshalable object http://bugs.jython.org/issue2077 #1925: Support loading java.sql.Drivers that aren't on the boot class http://bugs.jython.org/issue1925 #1917: No ctypes.c_char http://bugs.jython.org/issue1917 #1866: Parser does not have mismatch token error messages caught by B http://bugs.jython.org/issue1866 #1842: Add IBM i support to Jython http://bugs.jython.org/issue1842 Top 10 most discussed issues (1) ================================ #2650: Detail message is not set on PyException from PythonInterprete http://bugs.jython.org/issue2650 3 msgs |
|
From: Isaiah P. <is...@gm...> - 2018-01-04 18:13:23
|
Hi Jeff, That's not the problem that affects windows, i think on windows it requires the `winreg` module, which is not implemented. The `_frozen_importlib` is not normal blobs, it's the equivalent of cpython frozen module, which is the compiled code of the `importlib/_bootstrap` and `importlib/_bootstrap_external`, it's need to bootstrap the import machinery. The problem here is that it should use ClassLoader.getResourceAsStream to read the class file instead of using a hardcoded file reader. Cheers, Isaiah On Thu, 4 Jan 2018 at 19:02 Jeff Allen <ja...@fa...> wrote: > Hi Isaiah. > > Since that module stops Jython 3 running on Windows, it would be good to > have a little account of how to build it from source. There's a section in > the developer guide intended for that. ( > http://jython-devguide.readthedocs.io/en/jython/setup_jy.html#manually-regenerated-files > ) > > Generally we'd like to reduce/eliminate checked in blobs, but that's a > longer work. > Jeff > > Jeff Allen > > On 04/01/2018 10:00, Isaiah Peng wrote: > > The file is actually there, but since it uses relative path, you have to > execute the command with "dist/bin/jython". Hope it helps. > > On Thu, 4 Jan 2018 at 10:48 Isaiah Peng <is...@gm...> wrote: > >> Hi Patrick, >> >> That's my fault, I forgot to commit the "frozen" module, also the path is >> hardcoded, but will handle that later. >> Will let you know when I have a fix. >> >> Regards, >> Isaiah >> >> > |
|
From: Jeff A. <ja...@fa...> - 2018-01-04 18:02:16
|
Hi Isaiah. Since that module stops Jython 3 running on Windows, it would be good to have a little account of how to build it from source. There's a section in the developer guide intended for that. (http://jython-devguide.readthedocs.io/en/jython/setup_jy.html#manually-regenerated-files) Generally we'd like to reduce/eliminate checked in blobs, but that's a longer work. Jeff Jeff Allen On 04/01/2018 10:00, Isaiah Peng wrote: > The file is actually there, but since it uses relative path, you have > to execute the command with "dist/bin/jython". Hope it helps. > > On Thu, 4 Jan 2018 at 10:48 Isaiah Peng <is...@gm... > <mailto:is...@gm...>> wrote: > > Hi Patrick, > > That's my fault, I forgot to commit the "frozen" module, also the > path is hardcoded, but will handle that later. > Will let you know when I have a fix. > > Regards, > Isaiah > |
|
From: Isaiah P. <is...@gm...> - 2018-01-04 10:01:07
|
The file is actually there, but since it uses relative path, you have to execute the command with "dist/bin/jython". Hope it helps. On Thu, 4 Jan 2018 at 10:48 Isaiah Peng <is...@gm...> wrote: > Hi Patrick, > > That's my fault, I forgot to commit the "frozen" module, also the path is > hardcoded, but will handle that later. > Will let you know when I have a fix. > > Regards, > Isaiah > > On Thu, 4 Jan 2018 at 03:47 Patrick Palczewski <psy...@gm...> > wrote: > >> I was able to find the Jython3 package on GitHub, so I coned the >> reposaitory. >> >> I built it with Ant like I did for Jython 2.7.2a1+ (seeing no other >> instructions in the README file). It reported a successful build. I am >> using the openJDK-9 (well, my system says: javac 9-internal). Could that be >> the reson? I've had no problems until now and works when building 2.7.2. >> >> When I execute ./jython, I get the following: >> >> java.io.FileNotFoundException: >> src/resources/frozen_importlib/_frozen_importlib.class (No such file or >> directory) >> at java.io.FileInputStream.open0(Native Method) >> at java.io.FileInputStream.open(FileInputStream.java:195) >> at java.io.FileInputStream.<init>(FileInputStream.java:138) >> at org.python.core.PySystemState.doInitialize(PySystemState.java:1152) >> at org.python.core.PySystemState.initialize(PySystemState.java:1007) >> at org.python.core.PySystemState.initialize(PySystemState.java:962) >> at org.python.core.PySystemState.initialize(PySystemState.java:957) >> at org.python.util.jython.run(jython.java:254) >> at org.python.util.jython.main(jython.java:141) >> Exception in thread "main" java.lang.NullPointerException >> at org.python.core.imp.import_next(imp.java:735) >> at org.python.core.imp.import_first(imp.java:770) >> at org.python.core.imp.load(imp.java:616) >> at org.python.core.Py.importSiteIfSelected(Py.java:1922) >> at >> org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:114) >> at org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:92) >> at >> org.python.util.InteractiveInterpreter.<init>(InteractiveInterpreter.java:39) >> at >> org.python.util.InteractiveInterpreter.<init>(InteractiveInterpreter.java:28) >> at >> org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:68) >> at >> org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:54) >> at >> org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:34) >> at org.python.util.jython.run(jython.java:275) >> at org.python.util.jython. >> >> Should I build with a different Java? I have JDK1.8.0_151 and OpenJDK-8 >> also. >> >> My system is Ubuntu 16.04. >> >> >> Thanks, >> - *Patrick Palczewski* >> *VRS# 818.208.2344 <(818)%20208-2344>* >> *Sent from Thunderbird Mail for Linux* >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> > |
|
From: Isaiah P. <is...@gm...> - 2018-01-04 09:48:37
|
Hi Patrick, That's my fault, I forgot to commit the "frozen" module, also the path is hardcoded, but will handle that later. Will let you know when I have a fix. Regards, Isaiah On Thu, 4 Jan 2018 at 03:47 Patrick Palczewski <psy...@gm...> wrote: > I was able to find the Jython3 package on GitHub, so I coned the > reposaitory. > > I built it with Ant like I did for Jython 2.7.2a1+ (seeing no other > instructions in the README file). It reported a successful build. I am > using the openJDK-9 (well, my system says: javac 9-internal). Could that be > the reson? I've had no problems until now and works when building 2.7.2. > > When I execute ./jython, I get the following: > > java.io.FileNotFoundException: > src/resources/frozen_importlib/_frozen_importlib.class (No such file or > directory) > at java.io.FileInputStream.open0(Native Method) > at java.io.FileInputStream.open(FileInputStream.java:195) > at java.io.FileInputStream.<init>(FileInputStream.java:138) > at org.python.core.PySystemState.doInitialize(PySystemState.java:1152) > at org.python.core.PySystemState.initialize(PySystemState.java:1007) > at org.python.core.PySystemState.initialize(PySystemState.java:962) > at org.python.core.PySystemState.initialize(PySystemState.java:957) > at org.python.util.jython.run(jython.java:254) > at org.python.util.jython.main(jython.java:141) > Exception in thread "main" java.lang.NullPointerException > at org.python.core.imp.import_next(imp.java:735) > at org.python.core.imp.import_first(imp.java:770) > at org.python.core.imp.load(imp.java:616) > at org.python.core.Py.importSiteIfSelected(Py.java:1922) > at org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:114) > at org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:92) > at > org.python.util.InteractiveInterpreter.<init>(InteractiveInterpreter.java:39) > at > org.python.util.InteractiveInterpreter.<init>(InteractiveInterpreter.java:28) > at > org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:68) > at > org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:54) > at > org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:34) > at org.python.util.jython.run(jython.java:275) > at org.python.util.jython. > > Should I build with a different Java? I have JDK1.8.0_151 and OpenJDK-8 > also. > > My system is Ubuntu 16.04. > > > Thanks, > - *Patrick Palczewski* > *VRS# 818.208.2344 <(818)%20208-2344>* > *Sent from Thunderbird Mail for Linux* > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Patrick P. <psy...@gm...> - 2018-01-04 02:47:21
|
I was able to find the Jython3 package on GitHub, so I coned the reposaitory. I built it with Ant like I did for Jython 2.7.2a1+ (seeing no other instructions in the README file). It reported a successful build. I am using the openJDK-9 (well, my system says: javac 9-internal). Could that be the reson? I've had no problems until now and works when building 2.7.2. When I execute ./jython, I get the following: java.io.FileNotFoundException: src/resources/frozen_importlib/_frozen_importlib.class (No such file or directory) at java.io.FileInputStream.open0(Native Method) at java.io.FileInputStream.open(FileInputStream.java:195) at java.io.FileInputStream.<init>(FileInputStream.java:138) at org.python.core.PySystemState.doInitialize(PySystemState.java:1152) at org.python.core.PySystemState.initialize(PySystemState.java:1007) at org.python.core.PySystemState.initialize(PySystemState.java:962) at org.python.core.PySystemState.initialize(PySystemState.java:957) at org.python.util.jython.run(jython.java:254) at org.python.util.jython.main(jython.java:141) Exception in thread "main" java.lang.NullPointerException at org.python.core.imp.import_next(imp.java:735) at org.python.core.imp.import_first(imp.java:770) at org.python.core.imp.load(imp.java:616) at org.python.core.Py.importSiteIfSelected(Py.java:1922) at org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:114) at org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:92) at org.python.util.InteractiveInterpreter.<init>(InteractiveInterpreter.java:39) at org.python.util.InteractiveInterpreter.<init>(InteractiveInterpreter.java:28) at org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:68) at org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:54) at org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:34) at org.python.util.jython.run(jython.java:275) at org.python.util.jython. Should I build with a different Java? I have JDK1.8.0_151 and OpenJDK-8 also. My system is Ubuntu 16.04. Thanks, - *Patrick Palczewski* _VRS# 818.208.2344_ /Sent from Thunderbird Mail for Linux/ |
|
From: Jython t. <st...@bu...> - 2017-12-29 17:10:22
|
ACTIVITY SUMMARY (2017-12-22 - 2017-12-29) Jython tracker at http://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 ( +0) closed 2336 ( +0) total 2670 ( +0) Open issues with patches: 29 Most recent 15 issues with no replies (15) ========================================== #2651: Travis Builds failing with *** buffer overflow detected *** http://bugs.jython.org/issue2651 #2648: Show report on screen with Python and JasperReport http://bugs.jython.org/issue2648 #2645: pop method returns wrong result with Java LinkedList http://bugs.jython.org/issue2645 #2644: Representation of Java maps with String keys differs from Pyth http://bugs.jython.org/issue2644 #2642: ImportError when importing in multiple PyScriptEngine concurre http://bugs.jython.org/issue2642 #2640: Virtualenv gets confused using paths with ~ http://bugs.jython.org/issue2640 #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2633: Unicode garbled in writing to spreadsheet via openpyxl http://bugs.jython.org/issue2633 #2631: jython 2.7.1 [Errno 107] Socket is not connected http://bugs.jython.org/issue2631 #2618: socket.sendall no longer sends all http://bugs.jython.org/issue2618 #2616: Incomplete / broken support for Certificate Revocation Lists http://bugs.jython.org/issue2616 #2613: 2.7.1 MANIFEST.MF contains unfilled placeholders http://bugs.jython.org/issue2613 #2611: mkdir() operation in /Lib/os.py has different behavior when ru http://bugs.jython.org/issue2611 #2606: jython launch problem sun.misc.InvalidJarIndexException http://bugs.jython.org/issue2606 #2605: Jython 2.7.0 startup performance regression http://bugs.jython.org/issue2605 Most recent 15 issues waiting for review (15) ============================================= #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2566: inspect does not recognize code objects from bytecode files http://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules http://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the http://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses http://bugs.jython.org/issue2367 #2330: full-build fails to copy CPython License http://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core http://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar http://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context http://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries http://bugs.jython.org/issue2121 #2077: marshal doesn't raise error when fed unmarshalable object http://bugs.jython.org/issue2077 #1925: Support loading java.sql.Drivers that aren't on the boot class http://bugs.jython.org/issue1925 #1917: No ctypes.c_char http://bugs.jython.org/issue1917 #1866: Parser does not have mismatch token error messages caught by B http://bugs.jython.org/issue1866 #1842: Add IBM i support to Jython http://bugs.jython.org/issue1842 |
|
From: Jython t. <st...@bu...> - 2017-12-22 17:10:24
|
ACTIVITY SUMMARY (2017-12-15 - 2017-12-22) Jython tracker at http://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 2336 ( +0) total 2670 ( +1) Open issues with patches: 29 Issues opened (1) ================= #2651: Travis Builds failing with *** buffer overflow detected *** http://bugs.jython.org/issue2651 opened by jamesmudd Most recent 15 issues with no replies (15) ========================================== #2651: Travis Builds failing with *** buffer overflow detected *** http://bugs.jython.org/issue2651 #2648: Show report on screen with Python and JasperReport http://bugs.jython.org/issue2648 #2645: pop method returns wrong result with Java LinkedList http://bugs.jython.org/issue2645 #2644: Representation of Java maps with String keys differs from Pyth http://bugs.jython.org/issue2644 #2642: ImportError when importing in multiple PyScriptEngine concurre http://bugs.jython.org/issue2642 #2640: Virtualenv gets confused using paths with ~ http://bugs.jython.org/issue2640 #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2633: Unicode garbled in writing to spreadsheet via openpyxl http://bugs.jython.org/issue2633 #2631: jython 2.7.1 [Errno 107] Socket is not connected http://bugs.jython.org/issue2631 #2618: socket.sendall no longer sends all http://bugs.jython.org/issue2618 #2616: Incomplete / broken support for Certificate Revocation Lists http://bugs.jython.org/issue2616 #2613: 2.7.1 MANIFEST.MF contains unfilled placeholders http://bugs.jython.org/issue2613 #2611: mkdir() operation in /Lib/os.py has different behavior when ru http://bugs.jython.org/issue2611 #2606: jython launch problem sun.misc.InvalidJarIndexException http://bugs.jython.org/issue2606 #2605: Jython 2.7.0 startup performance regression http://bugs.jython.org/issue2605 Most recent 15 issues waiting for review (15) ============================================= #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2566: inspect does not recognize code objects from bytecode files http://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules http://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the http://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses http://bugs.jython.org/issue2367 #2330: full-build fails to copy CPython License http://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core http://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar http://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context http://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries http://bugs.jython.org/issue2121 #2077: marshal doesn't raise error when fed unmarshalable object http://bugs.jython.org/issue2077 #1925: Support loading java.sql.Drivers that aren't on the boot class http://bugs.jython.org/issue1925 #1917: No ctypes.c_char http://bugs.jython.org/issue1917 #1866: Parser does not have mismatch token error messages caught by B http://bugs.jython.org/issue1866 #1842: Add IBM i support to Jython http://bugs.jython.org/issue1842 |
|
From: Rory O'D. <ror...@or...> - 2017-12-18 10:14:22
|
Hi Alan, *JDK 10 entered Rampdown Phase One on Thursday, 14 December [1] * * The Rampdown Phase One process will be similar to that of JDK 9 [2]. *JDK 10 Early Access build 36 is available at : - jdk.java.net/10/* Notable changes since previous email. *JEPS included **the last 3 builds:* JDK-8192833 <https://bugs.openjdk.java.net/browse/JDK-8192833> :This is the primary implementation subtask of JEP 322 - *Time-Based Release Versioning* JDK-8189941 <https://bugs.openjdk.java.net/browse/JDK-8189941> : Implementation JEP 312: Thread-local handshake JDK-8186571 <https://bugs.openjdk.java.net/browse/JDK-8186571> : Implementation: JEP 307: Parallel Full GC for G1 JDK-8190308 <https://bugs.openjdk.java.net/browse/JDK-8190308> : Implementation: JEP 316: Heap Allocation on Alternative Memory Devices *build 36 *JDK-8148421 <https://bugs.openjdk.java.net/browse/JDK-8148421> : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension JDK-5016517 <https://bugs.openjdk.java.net/browse/JDK-5016517> : Replace plaintext passwords by hashed passwords for out-of-the-box JMX Agent ** *build 35 * JDK-8188870 <https://bugs.openjdk.java.net/browse/JDK-8188870> - Bump classfile version number to 54 JDK-8185985 <http://bugs.openjdk.java.net/browse/JDK-8185985> - HTML files in doc-files subdirectories are wrapped with standard javadoc decorations JDK-8186535 <http://bugs.openjdk.java.net/browse/JDK-8186535>*- *Remove deprecated pre-1.2 SecurityManager methods and fields *build 34* - JDK-8024352 <http://bugs.openjdk.java.net/browse/JDK-8024352> - MBeanOperationInfo accepts any int value as "impact" *Bug fixes reported by Open Source Projects :*<https://bugs.openjdk.java.net/browse/JDK-8191834> JDK-8191078 <https://bugs.openjdk.java.net/browse/JDK-8191078> : Wrong "Package not found" warning JDK-8191636 <https://bugs.openjdk.java.net/browse/JDK-8191636> : [Windows] jshell tool: Wrong character in /env class-path command crashes jshell JDK-8191834 <https://bugs.openjdk.java.net/browse/JDK-8191834> : Assigning a void expression to a "var" crashes the compiler<https://bugs.openjdk.java.net/browse/JDK-8182638> JDK-8182638 <https://bugs.openjdk.java.net/browse/JDK-8182638> : [macosx] Active modal dialog is hidden by another non-active one JDK-8043315 <https://bugs.openjdk.java.net/browse/JDK-8043315> : Nimbus: Setting Nimbus.Overrides property affects custom keymap installation JDK-8172244 <https://bugs.openjdk.java.net/browse/JDK-8172244> : AIOOBE in KeyStore.getCertificateAlias on Windows JDK-8180141 <https://bugs.openjdk.java.net/browse/JDK-8180141> : Missing entry in LineNumberTable for break statement that jumps out of try-finall JDK 10 Schedule, Status & Features are available [3] *Feedback* - If you have suggestions or encounter bugs, please submit them using the usual Java SE bug-reporting channel. Be sure to include complete version information from the output of the |java --version| command. Regards, Rory [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000357.html [2] http://openjdk.java.net/projects/jdk9/rdp-1 [3] http://openjdk.java.net/projects/jdk/10/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland |
|
From: Jython t. <st...@bu...> - 2017-12-15 17:10:23
|
ACTIVITY SUMMARY (2017-12-08 - 2017-12-15) Jython tracker at http://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 ( +0) closed 2336 ( +0) total 2669 ( +0) Open issues with patches: 29 Most recent 15 issues with no replies (15) ========================================== #2650: detailMessage is not set on PyException http://bugs.jython.org/issue2650 #2648: Show report on screen with Python and JasperReport http://bugs.jython.org/issue2648 #2645: pop method returns wrong result with Java LinkedList http://bugs.jython.org/issue2645 #2644: Representation of Java maps with String keys differs from Pyth http://bugs.jython.org/issue2644 #2642: ImportError when importing in multiple PyScriptEngine concurre http://bugs.jython.org/issue2642 #2640: Virtualenv gets confused using paths with ~ http://bugs.jython.org/issue2640 #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2633: Unicode garbled in writing to spreadsheet via openpyxl http://bugs.jython.org/issue2633 #2631: jython 2.7.1 [Errno 107] Socket is not connected http://bugs.jython.org/issue2631 #2618: socket.sendall no longer sends all http://bugs.jython.org/issue2618 #2616: Incomplete / broken support for Certificate Revocation Lists http://bugs.jython.org/issue2616 #2613: 2.7.1 MANIFEST.MF contains unfilled placeholders http://bugs.jython.org/issue2613 #2611: mkdir() operation in /Lib/os.py has different behavior when ru http://bugs.jython.org/issue2611 #2606: jython launch problem sun.misc.InvalidJarIndexException http://bugs.jython.org/issue2606 #2605: Jython 2.7.0 startup performance regression http://bugs.jython.org/issue2605 Most recent 15 issues waiting for review (15) ============================================= #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2566: inspect does not recognize code objects from bytecode files http://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules http://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the http://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses http://bugs.jython.org/issue2367 #2330: full-build fails to copy CPython License http://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core http://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar http://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context http://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries http://bugs.jython.org/issue2121 #2077: marshal doesn't raise error when fed unmarshalable object http://bugs.jython.org/issue2077 #1925: Support loading java.sql.Drivers that aren't on the boot class http://bugs.jython.org/issue1925 #1917: No ctypes.c_char http://bugs.jython.org/issue1917 #1866: Parser does not have mismatch token error messages caught by B http://bugs.jython.org/issue1866 #1842: Add IBM i support to Jython http://bugs.jython.org/issue1842 |
|
From: Jython t. <st...@bu...> - 2017-12-08 17:10:23
|
ACTIVITY SUMMARY (2017-12-01 - 2017-12-08) Jython tracker at http://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 ( +2) closed 2336 ( +0) total 2669 ( +2) Open issues with patches: 29 Issues opened (2) ================= #2649: GregorianCalendar.getDisplayNames() crashes with PyString erro http://bugs.jython.org/issue2649 opened by psykiatris #2650: detailMessage is not set on PyException http://bugs.jython.org/issue2650 opened by jamesmudd Most recent 15 issues with no replies (15) ========================================== #2650: detailMessage is not set on PyException http://bugs.jython.org/issue2650 #2648: Show report on screen with Python and JasperReport http://bugs.jython.org/issue2648 #2645: pop method returns wrong result with Java LinkedList http://bugs.jython.org/issue2645 #2644: Representation of Java maps with String keys differs from Pyth http://bugs.jython.org/issue2644 #2642: ImportError when importing in multiple PyScriptEngine concurre http://bugs.jython.org/issue2642 #2640: Virtualenv gets confused using paths with ~ http://bugs.jython.org/issue2640 #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2633: Unicode garbled in writing to spreadsheet via openpyxl http://bugs.jython.org/issue2633 #2631: jython 2.7.1 [Errno 107] Socket is not connected http://bugs.jython.org/issue2631 #2618: socket.sendall no longer sends all http://bugs.jython.org/issue2618 #2616: Incomplete / broken support for Certificate Revocation Lists http://bugs.jython.org/issue2616 #2613: 2.7.1 MANIFEST.MF contains unfilled placeholders http://bugs.jython.org/issue2613 #2611: mkdir() operation in /Lib/os.py has different behavior when ru http://bugs.jython.org/issue2611 #2606: jython launch problem sun.misc.InvalidJarIndexException http://bugs.jython.org/issue2606 #2605: Jython 2.7.0 startup performance regression http://bugs.jython.org/issue2605 Most recent 15 issues waiting for review (15) ============================================= #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2566: inspect does not recognize code objects from bytecode files http://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules http://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the http://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses http://bugs.jython.org/issue2367 #2330: full-build fails to copy CPython License http://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core http://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar http://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context http://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries http://bugs.jython.org/issue2121 #2077: marshal doesn't raise error when fed unmarshalable object http://bugs.jython.org/issue2077 #1925: Support loading java.sql.Drivers that aren't on the boot class http://bugs.jython.org/issue1925 #1917: No ctypes.c_char http://bugs.jython.org/issue1917 #1866: Parser does not have mismatch token error messages caught by B http://bugs.jython.org/issue1866 #1842: Add IBM i support to Jython http://bugs.jython.org/issue1842 |
|
From: Jython t. <st...@bu...> - 2017-12-01 17:10:23
|
ACTIVITY SUMMARY (2017-11-24 - 2017-12-01) Jython tracker at http://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 331 ( +2) closed 2336 ( +0) total 2667 ( +2) Open issues with patches: 29 Issues opened (2) ================= #2647: Py.newDateTime, Py.newTime should initialize timezone python d http://bugs.jython.org/issue2647 opened by tmeagher #2648: Show report on screen with Python and JasperReport http://bugs.jython.org/issue2648 opened by rmatarrita Most recent 15 issues with no replies (15) ========================================== #2648: Show report on screen with Python and JasperReport http://bugs.jython.org/issue2648 #2645: pop method returns wrong result with Java LinkedList http://bugs.jython.org/issue2645 #2644: Representation of Java maps with String keys differs from Pyth http://bugs.jython.org/issue2644 #2642: ImportError when importing in multiple PyScriptEngine concurre http://bugs.jython.org/issue2642 #2640: Virtualenv gets confused using paths with ~ http://bugs.jython.org/issue2640 #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2633: Unicode garbled in writing to spreadsheet via openpyxl http://bugs.jython.org/issue2633 #2631: jython 2.7.1 [Errno 107] Socket is not connected http://bugs.jython.org/issue2631 #2618: socket.sendall no longer sends all http://bugs.jython.org/issue2618 #2616: Incomplete / broken support for Certificate Revocation Lists http://bugs.jython.org/issue2616 #2613: 2.7.1 MANIFEST.MF contains unfilled placeholders http://bugs.jython.org/issue2613 #2611: mkdir() operation in /Lib/os.py has different behavior when ru http://bugs.jython.org/issue2611 #2606: jython launch problem sun.misc.InvalidJarIndexException http://bugs.jython.org/issue2606 #2605: Jython 2.7.0 startup performance regression http://bugs.jython.org/issue2605 #2591: Unable to execute directory or zip file (test_cmd_line_script) http://bugs.jython.org/issue2591 Most recent 15 issues waiting for review (15) ============================================= #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2566: inspect does not recognize code objects from bytecode files http://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules http://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the http://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses http://bugs.jython.org/issue2367 #2330: full-build fails to copy CPython License http://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core http://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar http://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context http://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries http://bugs.jython.org/issue2121 #2077: marshal doesn't raise error when fed unmarshalable object http://bugs.jython.org/issue2077 #1925: Support loading java.sql.Drivers that aren't on the boot class http://bugs.jython.org/issue1925 #1917: No ctypes.c_char http://bugs.jython.org/issue1917 #1866: Parser does not have mismatch token error messages caught by B http://bugs.jython.org/issue1866 #1842: Add IBM i support to Jython http://bugs.jython.org/issue1842 |
|
From: Jeff A. <ja...@fa...> - 2017-11-30 07:13:45
|
The point of having a copy of the list would be to prevent this:
>>> s = PyShadowString("hello", "bonjour")
>>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
>>> t = s[:3]
>>> t == "bon"
True
>>> s. gettargets().pop()
('org\\.python\\.util\\.InteractiveConsole',)
>>> t == "bon"
False
It is not a problem if the slice is only transient, as in if
sys.platform[:4] == 'java' , which I agree is the only sort of slicing
attested in the stdlib. If we imagine a slice getting a life of its own,
the behaviour above would be very confusing, but I'm happy to risk that
for now.
I think I have a decent implementation now of these several changes.
Jeff
Jeff Allen
On 27/11/2017 21:31, Stefan Richthofer wrote:
> > I wonder why we write if sys.platform[:4] == 'java' anyway. It's
> more work than startswith and you have to count to 4 yourself.
> It's a matter of fact that external libraries sometimes use slicing
> for platform check. So far the implementation served all use cases I
> found.
> > suggest we expect PyShadowString(a, b)[m,n] to be
> PyShadowString(a[m,n], b[m,n]), and I can see advantages to that.
> Good spot. Luckily this is mostly used for "win" which is shorter than
> "java", but of course your version is safer and more correct.
> Please let's apply that.
> > Also, if the targets list is mutable, I think each slice must have
> its own.
> I'm not sure if that is necessary. At least for all use cases I know
> it is fine if the slice inherits or shares target list from/with the
> original PyShadowString. Do I overlook something?
> *Gesendet:* Montag, 27. November 2017 um 21:33 Uhr
> *Von:* "Jeff Allen" <ja...@fa...>
> *An:* "Stefan Richthofer" <Ste...@gm...>
> *Cc:* "Jython Developers" <jyt...@li...>
> *Betreff:* Re: PyShadowString test, ideas, questions
>
> Thanks Stefan:
>
> I'm happy with your answers. I have tried isBaseType = true and can
> run the str tests now (passes of course). I've added a *Derived.java file.
>
> 7. Slicing is interesting. Nice touch.
>
> >>> s = PyShadowString("hello", "bonjour")
> >>> s[:3]
> 'hel ( ==bon for targets )'
>
> I appreciate the main use case is sys.platform[:n] , but these were
> surprising (because the slice is only interpreted relative to the main
> string):
>
> >>> s[:7]
> 'hello ( ==bonjo for targets )'
>
> >>> s[-3:]
> 'llo ( ==njo for targets )'
>
> I suggest we expect PyShadowString(a, b)[m,n] to be
> PyShadowString(a[m,n], b[m,n]), and I can see advantages to that.
> Also, if the targets list is mutable, I think each slice must have its
> own.
>
> I wonder why we write if sys.platform[:4] == 'java' anyway. It's more
> work than startswith and you have to count to 4 yourself.
>
> Jeff
>
> Jeff Allen
> On 26/11/2017 10:16, Stefan Richthofer wrote:
>
> Trying to give answers as far as I have them...
>
> 1. Should I be able to do this?
>
> >>> s.gettargets().pop()
> ('org\\.python\\.util\\.InteractiveConsole',)
> >>> s == 'bonjour'
> False
>
> I think that's okay. target list is not private to alow
> monkeypatching etc in usual Python fashion.
>
> 2. This seems like a useful "unconditional", but I wonder if it is
> harmful:
>
> >>> s.addtarget(None)
> >>> s == 'bonjour'
> True
>
> No opinion. This behavior looks okay to me. Whoever uses
> PyShadowString must be aware of entering evil zone anyway.
>
> 3. Confusing subject, but I'm not sure the exposure of __eq__ is
> "canonical". I think the convention is __eq__ just wraps
> shadowstr___eq__, as done for startswith and __repr__, but here
> there is "added value" in __eq__ (also in PyString.__eq__).
> shadowstr___eq__ will be exposed as __eq__, and shouldn't
> PyShadowString.__eq__ do the same thing? What we need is
> complicated by the wrapper PyObject._eq.
>
> I think you're right. The check for isTarget should be moved to
> shadowstr___eq__ I suppose. Sorry I overlooked this when I wrote it.
>
> 4. Single-stepping through __eq__ I notice that a call like s ==
> 'bonjour' (i.e. a call to __eq__) is quite costly, even when there
> are no targets that match. The problem is in isTarget() and so I
> think I will try changing the logic to:
>
> return other==string || (other==shadow && isTarget())
>
> but also, we can make isTarget() cheaper.
>
> Thats' s a good improvement. Also, isTarget should fail-fast if
> target list is empty (I thought I had done it that way).On the
> other hand, performance is hardly a priority here, because
> platform checks are usually rather seldom, mostly on startup only.
>
> 5. I tried the tests of str on PyShadowString, to prove it is also
> a str, but they fail because it cannot be sub-classed. Is there a
> reason to prevent sub-classing?
>
> This is because of isBaseType = false? We can remove that. I just
> felt that shadow string contains enough magic and should not be
> further extended, but there is no concrete reason. We can allow
> subclassing.
>
> 6. And relatedly, when I was working on PyType I noticed that it
> is possible to expose a Java sub-class as the same Python type as
> its parent. This would mean that type(PyShadowString("a", "b"))
> would be str even though the behaviour is different. This sounds
> worth trying.
>
> Hmm, I don't like that. ShadowString is not a string and its type
> should be labled accordingly.
>
> *Gesendet:* Sonntag, 26. November 2017 um 09:06 Uhr
> *Von:* "Jeff Allen" <ja...@fa...>
> *An:* "Jython Developers" <jyt...@li...>,
> "Stefan Richthofer" <Ste...@gm...>
> *Betreff:* PyShadowString test, ideas, questions
>
> I've added a test for PyShadowString, our string that can have two
> values at once. Trying to design a test raises some questions.
>
> >>> s = PyShadowString("hello", "bonjour")
> >>> s == 'bonjour'
> False
> >>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
> >>> s == 'bonjour'
> True
>
> So far so good.
>
> 1. Should I be able to do this?
>
> >>> s.gettargets().pop()
> ('org\\.python\\.util\\.InteractiveConsole',)
> >>> s == 'bonjour'
> False
>
> 2. This seems like a useful "unconditional", but I wonder if it is
> harmful:
>
> >>> s.addtarget(None)
> >>> s == 'bonjour'
> True
>
> 3. Confusing subject, but I'm not sure the exposure of __eq__ is
> "canonical". I think the convention is __eq__ just wraps
> shadowstr___eq__, as done for startswith and __repr__, but here
> there is "added value" in __eq__ (also in PyString.__eq__).
> shadowstr___eq__ will be exposed as __eq__, and shouldn't
> PyShadowString.__eq__ do the same thing? What we need is
> complicated by the wrapper PyObject._eq.
>
> 4. Single-stepping through __eq__ I notice that a call like s ==
> 'bonjour' (i.e. a call to __eq__) is quite costly, even when there
> are no targets that match. The problem is in isTarget() and so I
> think I will try changing the logic to:
>
> return other==string || (other==shadow && isTarget())
>
> but also, we can make isTarget() cheaper.
>
> 5. I tried the tests of str on PyShadowString, to prove it is also
> a str, but they fail because it cannot be sub-classed. Is there a
> reason to prevent sub-classing?
>
> 6. And relatedly, when I was working on PyType I noticed that it
> is possible to expose a Java sub-class as the same Python type as
> its parent. This would mean that type(PyShadowString("a", "b"))
> would be str even though the behaviour is different. This sounds
> worth trying.
>
> Jeff
>
> --
> Jeff Allen
>
|
|
From: Rory O'D. <ror...@or...> - 2017-11-28 15:31:05
|
Hi Alan, *JDK 10 Early Access build 33 is available at : - **jdk.java.net/10/* Notable changes since previous email. <http://bugs.openjdk.java.net/browse/JDK-8175094>JDK-8180019 <http://bugs.openjdk.java.net/browse/JDK-8180019> - *javadoc treats failure to access a URL as an error , not a warning.* If javadoc cannot access the contents of a URL provided with the -link or -linkoffline options,the tool will now report an error. Previously, the tool continued with a warning, producing incorrect documentation output. JDK-8175094 <http://bugs.openjdk.java.net/browse/JDK-8175094>*- **The java.security.acl APIs are deprecated, for removal**** * The deprecated java.security.acl APIs are now marked with forRemoval=true and are subject to removal in a future version of Java SE. JDK-8175091 <http://bugs.openjdk.java.net/browse/JDK-8175091> *- The java.security.{Certificate,Identity,IdentityScope,Signer} APIs are deprecated, for removal* The deprecated java.security.{Certificate, Identity, IdentityScope, Signer} classes are now marked with forRemoval=true and are subject to removal in a future version of Java SE. JDK 10 Schedule, Status & Features are available [1] Notes * OpenJDK EA binaries will be available at a later date. * Oracle has proposed: Newer version-string scheme for the Java SE Platform and the JDK o Please see Mark Reinhold's proposal [2] *JDK 8u162 Early Access build 03 is available at :- http://jdk.java.net/8/* <http://openjdk.java.net/projects/jdk8u/releases/8u162.html> *Feedback* - If you have suggestions or encounter bugs, please submit them using the usual Java SE bug-reporting channel. Be sure to include complete version information from the output of the |java --version| command. Regards, Rory [1] http://openjdk.java.net/projects/jdk/10/ [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000089.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland |
|
From: Jeff A. <ja...@fa...> - 2017-11-27 21:14:57
|
Thanks Stefan:
I'm happy with your answers. I have tried isBaseType = true and can run
the str tests now (passes of course). I've added a *Derived.java file.
7. Slicing is interesting. Nice touch.
>>> s = PyShadowString("hello", "bonjour")
>>> s[:3]
'hel ( ==bon for targets )'
I appreciate the main use case is sys.platform[:n] , but these were
surprising (because the slice is only interpreted relative to the main
string):
>>> s[:7]
'hello ( ==bonjo for targets )'
>>> s[-3:]
'llo ( ==njo for targets )'
I suggest we expect PyShadowString(a, b)[m,n] to be
PyShadowString(a[m,n], b[m,n]), and I can see advantages to that. Also,
if the targets list is mutable, I think each slice must have its own.
I wonder why we write if sys.platform[:4] == 'java' anyway. It's more
work than startswith and you have to count to 4 yourself.
Jeff
Jeff Allen
On 26/11/2017 10:16, Stefan Richthofer wrote:
> Trying to give answers as far as I have them...
>
> 1. Should I be able to do this?
>
> >>> s.gettargets().pop()
> ('org\\.python\\.util\\.InteractiveConsole',)
> >>> s == 'bonjour'
> False
>
> I think that's okay. target list is not private to alow monkeypatching
> etc in usual Python fashion.
>
> 2. This seems like a useful "unconditional", but I wonder if it is
> harmful:
>
> >>> s.addtarget(None)
> >>> s == 'bonjour'
> True
>
> No opinion. This behavior looks okay to me. Whoever uses
> PyShadowString must be aware of entering evil zone anyway.
>
> 3. Confusing subject, but I'm not sure the exposure of __eq__ is
> "canonical". I think the convention is __eq__ just wraps
> shadowstr___eq__, as done for startswith and __repr__, but here there
> is "added value" in __eq__ (also in PyString.__eq__). shadowstr___eq__
> will be exposed as __eq__, and shouldn't PyShadowString.__eq__ do the
> same thing? What we need is complicated by the wrapper PyObject._eq.
>
> I think you're right. The check for isTarget should be moved to
> shadowstr___eq__ I suppose. Sorry I overlooked this when I wrote it.
>
> 4. Single-stepping through __eq__ I notice that a call like s ==
> 'bonjour' (i.e. a call to __eq__) is quite costly, even when there are
> no targets that match. The problem is in isTarget() and so I think I
> will try changing the logic to:
>
> return other==string || (other==shadow && isTarget())
>
> but also, we can make isTarget() cheaper.
>
> Thats' s a good improvement. Also, isTarget should fail-fast if target
> list is empty (I thought I had done it that way).On the other hand,
> performance is hardly a priority here, because platform checks are
> usually rather seldom, mostly on startup only.
>
> 5. I tried the tests of str on PyShadowString, to prove it is also a
> str, but they fail because it cannot be sub-classed. Is there a reason
> to prevent sub-classing?
>
> This is because of isBaseType = false? We can remove that. I just felt
> that shadow string contains enough magic and should not be further
> extended, but there is no concrete reason. We can allow subclassing.
>
> 6. And relatedly, when I was working on PyType I noticed that it is
> possible to expose a Java sub-class as the same Python type as its
> parent. This would mean that type(PyShadowString("a", "b")) would be
> str even though the behaviour is different. This sounds worth trying.
>
> Hmm, I don't like that. ShadowString is not a string and its type
> should be labled accordingly.
>
> *Gesendet:* Sonntag, 26. November 2017 um 09:06 Uhr
> *Von:* "Jeff Allen" <ja...@fa...>
> *An:* "Jython Developers" <jyt...@li...>, "Stefan
> Richthofer" <Ste...@gm...>
> *Betreff:* PyShadowString test, ideas, questions
>
> I've added a test for PyShadowString, our string that can have two
> values at once. Trying to design a test raises some questions.
>
> >>> s = PyShadowString("hello", "bonjour")
> >>> s == 'bonjour'
> False
> >>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
> >>> s == 'bonjour'
> True
>
> So far so good.
>
> 1. Should I be able to do this?
>
> >>> s.gettargets().pop()
> ('org\\.python\\.util\\.InteractiveConsole',)
> >>> s == 'bonjour'
> False
>
> 2. This seems like a useful "unconditional", but I wonder if it is
> harmful:
>
> >>> s.addtarget(None)
> >>> s == 'bonjour'
> True
>
> 3. Confusing subject, but I'm not sure the exposure of __eq__ is
> "canonical". I think the convention is __eq__ just wraps
> shadowstr___eq__, as done for startswith and __repr__, but here there
> is "added value" in __eq__ (also in PyString.__eq__). shadowstr___eq__
> will be exposed as __eq__, and shouldn't PyShadowString.__eq__ do the
> same thing? What we need is complicated by the wrapper PyObject._eq.
>
> 4. Single-stepping through __eq__ I notice that a call like s ==
> 'bonjour' (i.e. a call to __eq__) is quite costly, even when there are
> no targets that match. The problem is in isTarget() and so I think I
> will try changing the logic to:
>
> return other==string || (other==shadow && isTarget())
>
> but also, we can make isTarget() cheaper.
>
> 5. I tried the tests of str on PyShadowString, to prove it is also a
> str, but they fail because it cannot be sub-classed. Is there a reason
> to prevent sub-classing?
>
> 6. And relatedly, when I was working on PyType I noticed that it is
> possible to expose a Java sub-class as the same Python type as its
> parent. This would mean that type(PyShadowString("a", "b")) would be
> str even though the behaviour is different. This sounds worth trying.
>
> Jeff
>
> --
> Jeff Allen
|
|
From: Jeff A. <ja...@fa...> - 2017-11-26 19:17:09
|
I went with my instinct about the +. Not on the tagged version, then added in the next change. But maybe the next change should be to a2+, if + means "approaching" rather than "beyond". I found one reference for the CPython convention (possibly a Subversion convention): http://effbot.org/pyfaq/how-does-the-python-version-numbering-scheme-work.htm, but it's gone from the modern FAQ. What we should be doing is laid out in https://www.python.org/dev/peps/pep-0440/, which has a lot to say about releases of anything in the PyPI ecosystem, but nothing about non-releases. We comply in the sense that 2.7.2a1 is a compliant version identifier. 2.7.2a1+ violates PEP 440, so it does not identify a release, which in a sense is what we wanted to say. Jeff Allen On 22/11/2017 22:17, fwi...@gm... wrote: > Hi Jeff, > > That looks right except (as you where guessing) jython.version should be: > > <property name="jython.version" value="2.7.2a1+"/> > > The plus is a convention copied from CPython that I'm pretty sure > means that this is still in development and is not the tagged 2.7.2a1. > The reason we have a "noplus" version if I'm remembering correctly is > that the + doesn't work as part of a name for the maven packages. > > As for tagging: > > I think I'm the only one with the permissions on maven to actually > push a package, though I'm happy to share the responsibility :) -- let > me know and I will look into how you get those rights if you want > them. I think anyone can tag a release, but it probably makes sense > for the person who pushes the release to be the same as the one who > tags it. > > Thanks for moving this forward! > > -Frank > > On Wed, Nov 22, 2017 at 1:08 PM, Jeff Allen <ja...@fa...> wrote: >> Thanks Frank. 2nd or 27th Feb, perhaps. >> >> As you're the expert in this, can I ask am I doing this right (in build.xml, >> obviously): >> >> <!-- The current version info --> >> <property name="jython.version" value="2.7.2a1"/> >> <property name="jython.version.noplus" value="2.7.2a1"/> >> <property name="jython.major_version" value="2"/> >> <property name="jython.minor_version" value="7"/> >> <property name="jython.micro_version" value="2"/> >> <property name="jython.release_level" >> value="${PY_RELEASE_LEVEL_ALPHA}"/> >> <property name="jython.release_serial" value="1"/> >> >> In history, I see we commit this type of change, then there's a commit with >> a tag. Am I able to push a change that adds a tag? ISTR there's a >> restriction. >> >> When do we add the + to a version? (We seem to have forgotten so far in >> 2.7.1.) Does the plus have a magical effect somewhere? >> >> Jeff >> >> Jeff Allen >> >> On 22/11/2017 19:42, fwi...@gm... wrote: >> >> A new year's 2.7.2 with a limited scope is definitely a great idea, as >> is an updated GitHub based website. I'm on board! >> >> -Frank >> >> On Tue, Nov 21, 2017 at 3:32 PM, Jeff Allen <ja...@fa...> wrote: >> >> All: >> >> How about it? This seems like a reasonable interval since 2.7.1. >> >> Frank/Jim: would you care to set a goal? What else ought we to have in that >> release? >> >> I think we should mean by the answer, what we'd like to see in 2.7.2b1. Then >> we only take on fixes during beta we didn't foresee or can't avoid. That >> way, we hopefully don't stay in beta very long. I'm extrapolating a bit from >> https://github.com/jython/devguide/blob/jython/devcycle.rst#stages (cloned >> from CPython) but it seems a good discipline to prevent late de-stabilising >> change. >> >> Is it perhaps as important to create a revised web site to back the release? >> (We have talked about a site we can all contribute to via GitHub.) >> >> Also, I've been meaning to ask, the current dev tip should identify as >> "2.7.1+" (not plain "2.7.1") shouldn't it? And 2.7.2a1 then 2.7.2a1+ as soon >> as we decide we're having a 2.7.2? I think I see how this works in >> build.xml. >> >> Jeff >> >> -- >> Jeff Allen >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> >> |
|
From: Jeff A. <ja...@fa...> - 2017-11-26 08:06:39
|
I've added a test for PyShadowString, our string that can have two
values at once. Trying to design a test raises some questions.
>>> s = PyShadowString("hello", "bonjour")
>>> s == 'bonjour'
False
>>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
>>> s == 'bonjour'
True
So far so good.
1. Should I be able to do this?
>>> s.gettargets().pop()
('org\\.python\\.util\\.InteractiveConsole',)
>>> s == 'bonjour'
False
2. This seems like a useful "unconditional", but I wonder if it is harmful:
>>> s.addtarget(None)
>>> s == 'bonjour'
True
3. Confusing subject, but I'm not sure the exposure of __eq__ is
"canonical". I think the convention is __eq__ just wraps
shadowstr___eq__, as done for startswith and __repr__, but here there is
"added value" in __eq__ (also in PyString.__eq__). shadowstr___eq__ will
be exposed as __eq__, and shouldn't PyShadowString.__eq__ do the same
thing? What we need is complicated by the wrapper PyObject._eq.
4. Single-stepping through __eq__ I notice that a call like s ==
'bonjour' (i.e. a call to __eq__) is quite costly, even when there are
no targets that match. The problem is in isTarget() and so I think I
will try changing the logic to:
return other==string || (other==shadow && isTarget())
but also, we can make isTarget() cheaper.
5. I tried the tests of str on PyShadowString, to prove it is also a
str, but they fail because it cannot be sub-classed. Is there a reason
to prevent sub-classing?
6. And relatedly, when I was working on PyType I noticed that it is
possible to expose a Java sub-class as the same Python type as its
parent. This would mean that type(PyShadowString("a", "b")) would be str
even though the behaviour is different. This sounds worth trying.
Jeff
--
Jeff Allen
|
|
From: Jeff A. <ja...@fa...> - 2017-11-25 16:33:34
|
Hi Stefan:
If the tests are not a good driver for us, I think it follows we need to
start with Java unit tests of implementation-level features. There are
some in the code base, but of course they need updating to 3.
With regard to this:
"For the official Jython 3 repository, it's probably best to switch
to CPython workflow.
The switch from Jython 2.7 to 3 is IMHO the ideal opportunity to
switch the workflow as well. Given our limited resources I would
recommend not to spend time on migrating Jython 2.7 workflow to
CPython."
The idea of revisiting the dev guide was to adopt the CPython flow for
Jython. I think it can work to use it for Jython 3 while we continue to
use our old flow for Jython 2. I was trying that in the sand box. But
only for a time, as we need to move out of hg.python.org so as not to be
a support burden. I was tentatively thinking we might do that when 2.7.2
releases. I'd like to see us adopt the tools CPython have created
(bedevere, knight-who-say-ni, etc. as needed).
For CPython, issues are on the traditional tracker. (Their devguide
issues & contribution process is fully based in GitHub.) As we have no
Jython 3 bugs on our tracker, we could perhaps start as we mean to go on.
This is suddenly exciting again.
Jeff
Adam: impressed by your metadata "在 2017年11月24日，上午9:44" etc.. I hope
this means you're testing our Unicode support!
Jeff Allen
On 24/11/2017 16:24, Stefan Richthofer wrote:
> I think it should ideally be something like langauage-wise (syntax,
> bytecode, import mechanism, other things like that) target 3.7, API
> and library wise target a subset first, maybe 3.5 (leaving out modules
> deprecated or vastly refractured in 3.6 or 3.7).
> > Or are they all only useful once Jython 3 works 80%?
> That's what I mean by a roadmp. I think there are some major changes
> from 2.7 to 3.5 that should be implemented before reasonable testing
> and test-driven development can start. I just don't know exactly what
> those are (besides replacing PyString by PyUnicode and getting rid of
> old-style classes). But I'm sure these can be looked up somewhere in
> the Python resources.
> Regarding git, I'd use its features to export and import commits as
> diff-files. I'd fork Jython 2.7 on github, so that new commits can be
> pulled from there. Then I'd clone Jython 3 sandbox and export all
> commits after it diverged from 2.7 branch to diff files. And then
> somehow work through them. Apply one by one, solve conflicts and run
> tests or at least assert runnability.
> It's a lot of work, but it has to get started somehow.
> For the official Jython 3 repository, it's probably best to switch to
> CPython workflow.
> The switch from Jython 2.7 to 3 is IMHO the ideal opportunity to
> switch the workflow as well. Given our limited resources I would
> recommend not to spend time on migrating Jython 2.7 workflow to CPython.
> *Gesendet:* Freitag, 24. November 2017 um 14:06 Uhr
> *Von:* "Adam Burke" <ada...@gm...>
> *An:* Kein Empfänger
> *Cc:* "Jython Developers" <jyt...@li...>
> *Betreff:* Re: [Jython-dev] Ascent of Jython 3
> From the sidelines:
> Are there any meaningful subsets of 3.7 features / testpack which
> could make usable intermediate milestones?
>
> Cheers
> Adam
>
> 在 2017年11月24日，上午9:44，Jim Baker <jim...@py...
> <mailto:jim...@py...>> 写道：
>
> I like the idea of starting from 2.7.2, and reaching back to the
> jython3 sandbox as it makes sense. One logical commit, followed by
> another, with tests passing as we converge on 3.7 (I assume it's
> easier to just target that version). The biggest immediate
> challenge will probably be around importlib logic, this is what is
> failing in the sandbox when I last looked at it.
> I suggest we do all of this in GitHub, under let's say a 3.7
> branch of github.com/jython/jython
> <http://github.com/jython/jython>. We can start by stripping out
> binaries - the jython.exe and everything in extlibs/ It's easy
> enough to retrieve from maven the necessary libraries, and it
> would be much better to have this be anything but something
> hardcoded going forward.
> On Thu, Nov 23, 2017 at 4:34 PM, Jeff Allen <ja...@fa...
> <mailto:ja...@fa...>> wrote:
>
> (Starting a new thread for this.)
>
> Stefan:
>
> It is a good reminder that the repository in question is
> described as a "sandbox". It's largely un-reviewed work,
> outside the official repository. However, there's quite a lot
> of sand in the box.
>
> What you propose sounds good to me. So the idea is a branch
> from Jython 2.7.2. I am visualising this in GitHub. Do you
> imagine we would have moved 2.7 work to GitHub first? Or does
> the plan work while we are still mastered at hg.python.org
> <http://hg.python.org> and feeding a 2.7 branch that way?
>
> I couldn't imagine the mechanics when first I considered it,
> but have more knowledge of git now. The fusing of our dev
> guide back into a fork of the CPython dev guide is perhaps a
> microcosm and was good training.
>
> All the work I've done on Jython has been driven by Python
> regression tests, although the proportion of failures has
> always been fairly small. Do you think it would work to begin
> by adding the tests for Python 3.7 (or maybe aim a little
> lower), and repeatedly throwing ourselves at that rock face?
> The tests of course would fail massively at first. Or are they
> all only useful once Jython 3 works 80%?
>
> As when we discussed this previously, though, I'm unable to
> imagine an automated process for merging change, unless
> "automated" encompasses long hours spent with KDiff3. When
> you've nearly-bulk replaced PyString with PyUnicode, for
> example, how is *any* merge going to run smoothly?
>
> Jeff
>
> On 23/11/2017 19:01, Stefan Richthofer wrote:
>
> > Merging means pulling from 2.7 to 3, I think.
> I'm actually going to try it the other way round.
> The current situation with Jython 3 concerns me a bit. It
> seems to
> be in a state where it is unclear how to proceed. This
> makes it
> somewhat discouraging to work on it. So I think we need a
> proper
> plan how to go on. I'd suggest the following:
> We open a new fresh Jython 3 that starts at Jython 2.7.2
> release.
> Keep in mind that the Jython 3 repository is actually a
> *sandbox*
> so far. We merge every commit done to Jython 3 sandbox
> since it
> was forked from 2.7, (hopefully mainly via automatic merge
> mechanism). This is the ideal opportunity to triage the issue
> with broken Windows support and to review Isaiahs work. While
> he did a lot great work on Jython 3 we must keep in mind
> that it
> has been hardly reviewed so far.
> I hope we can end up with a workable Jython 3 containing
> all the
> bugfixes and improvements that were added in Jython 2.7.1
> and 2.
> Problematic commits can be sorted out for later additional
> review.
> Regarding some aspects I propose to directly target Python
> 3.7, e.g.
> bytecode level and language syntax. Going through intermediate
> versions would be multiple work here.
> Besides this merging work we will need a real roadmap that
> states
> all the milestones and steps required for a Jython 3
> release. Who
> of us knows Python well enough to put this together? Jim?
> Frank?
> After merging is done we need a clear policy about
> backporting etc.
> I'd suggest to focus on Jython 3 then and only backport
> crucial or
> cherry-picked bugfixed to 2.7 branch.
> In the sprint I'll start an inofficial experimental Jython
> 3 to work on merging.
> This can maybe form the basis for an official non-sandbox
> Jython 3.
> Thoughts?
> -Stefan
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org <http://Slashdot.org>!
> http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> <mailto:Jyt...@li...>
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org <http://Slashdot.org>!
> http://sdm.link/slashdot
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> <mailto:Jyt...@li...>
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org!
> http://sdm.link/slashdot_______________________________________________
> Jython-dev mailing list Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
|
|
From: Jython t. <st...@bu...> - 2017-11-24 17:10:23
|
ACTIVITY SUMMARY (2017-11-17 - 2017-11-24) Jython tracker at http://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 329 ( +4) closed 2336 ( +0) total 2665 ( +4) Open issues with patches: 29 Issues opened (4) ================= #2643: time.clock() returning The Wrong Thing on Linux http://bugs.jython.org/issue2643 opened by zsd #2644: Representation of Java maps with String keys differs from Pyth http://bugs.jython.org/issue2644 opened by jamesmudd #2645: pop method returns wrong result with Java LinkedList http://bugs.jython.org/issue2645 opened by jamesmudd #2646: Test failure in test_os_jy after utf-8 decode http://bugs.jython.org/issue2646 opened by jamesmudd Most recent 15 issues with no replies (15) ========================================== #2645: pop method returns wrong result with Java LinkedList http://bugs.jython.org/issue2645 #2644: Representation of Java maps with String keys differs from Pyth http://bugs.jython.org/issue2644 #2642: ImportError when importing in multiple PyScriptEngine concurre http://bugs.jython.org/issue2642 #2640: Virtualenv gets confused using paths with ~ http://bugs.jython.org/issue2640 #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2633: Unicode garbled in writing to spreadsheet via openpyxl http://bugs.jython.org/issue2633 #2631: jython 2.7.1 [Errno 107] Socket is not connected http://bugs.jython.org/issue2631 #2618: socket.sendall no longer sends all http://bugs.jython.org/issue2618 #2616: Incomplete / broken support for Certificate Revocation Lists http://bugs.jython.org/issue2616 #2613: 2.7.1 MANIFEST.MF contains unfilled placeholders http://bugs.jython.org/issue2613 #2611: mkdir() operation in /Lib/os.py has different behavior when ru http://bugs.jython.org/issue2611 #2606: jython launch problem sun.misc.InvalidJarIndexException http://bugs.jython.org/issue2606 #2605: Jython 2.7.0 startup performance regression http://bugs.jython.org/issue2605 #2591: Unable to execute directory or zip file (test_cmd_line_script) http://bugs.jython.org/issue2591 #2567: System state lost during JSR-223 initialisation http://bugs.jython.org/issue2567 Most recent 15 issues waiting for review (15) ============================================= #2635: AST.lineno ignored by compile http://bugs.jython.org/issue2635 #2566: inspect does not recognize code objects from bytecode files http://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules http://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the http://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses http://bugs.jython.org/issue2367 #2330: full-build fails to copy CPython License http://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core http://bugs.jython.org/issue2230 #2143: site-packages support in standalone jar http://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context http://bugs.jython.org/issue2142 #2121: Jython jar on Maven central embeds other third party libraries http://bugs.jython.org/issue2121 #2077: marshal doesn't raise error when fed unmarshalable object http://bugs.jython.org/issue2077 #1925: Support loading java.sql.Drivers that aren't on the boot class http://bugs.jython.org/issue1925 #1917: No ctypes.c_char http://bugs.jython.org/issue1917 #1866: Parser does not have mismatch token error messages caught by B http://bugs.jython.org/issue1866 #1842: Add IBM i support to Jython http://bugs.jython.org/issue1842 Top 10 most discussed issues (2) ================================ #2638: str not default-decoded in str-unicode operations http://bugs.jython.org/issue2638 7 msgs #2643: time.clock() returning The Wrong Thing on Linux http://bugs.jython.org/issue2643 6 msgs |
|
From: Stefan R. <Ste...@gm...> - 2017-11-24 16:24:28
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>I think it should ideally be something like langauage-wise (syntax, bytecode, import mechanism, other things like that) target 3.7, API and library wise target a subset first, maybe 3.5 (leaving out modules deprecated or vastly refractured in 3.6 or 3.7).</div> <div> </div> <div>> Or are they all only useful once Jython 3 works 80%?</div> <div>That's what I mean by a roadmp. I think there are some major changes from 2.7 to 3.5 that should be implemented before reasonable testing and test-driven development can start. I just don't know exactly what those are (besides replacing PyString by PyUnicode and getting rid of old-style classes). But I'm sure these can be looked up somewhere in the Python resources.</div> <div> </div> <div>Regarding git, I'd use its features to export and import commits as diff-files. I'd fork Jython 2.7 on github, so that new commits can be pulled from there. Then I'd clone Jython 3 sandbox and export all commits after it diverged from 2.7 branch to diff files. And then somehow work through them. Apply one by one, solve conflicts and run tests or at least assert runnability.</div> <div>It's a lot of work, but it has to get started somehow.</div> <div> </div> <div>For the official Jython 3 repository, it's probably best to switch to CPython workflow.</div> <div>The switch from Jython 2.7 to 3 is IMHO the ideal opportunity to switch the workflow as well. Given our limited resources I would recommend not to spend time on migrating Jython 2.7 workflow to CPython.</div> <div> </div> <div> <div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);"> <div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b> Freitag, 24. November 2017 um 14:06 Uhr<br/> <b>Von:</b> "Adam Burke" <ada...@gm...><br/> <b>An:</b> Kein Empfänger<br/> <b>Cc:</b> "Jython Developers" <jyt...@li...><br/> <b>Betreff:</b> Re: [Jython-dev] Ascent of Jython 3</div> <div> <div>From the sidelines: <div> </div> <div>Are there any meaningful subsets of 3.7 features / testpack which could make usable intermediate milestones?<br/> <br/> Cheers <div id="AppleMailSignature">Adam</div> <div><br/> 在 2017年11月24日，上午9:44，Jim Baker <<a href="mailto:jim...@py..." onclick="parent.window.location.href='jim...@py...'; return false;" target="_blank">jim...@py...</a>> 写道：<br/> </div> <blockquote> <div> <div>I like the idea of starting from 2.7.2, and reaching back to the jython3 sandbox as it makes sense. One logical commit, followed by another, with tests passing as we converge on 3.7 (I assume it's easier to just target that version). The biggest immediate challenge will probably be around importlib logic, this is what is failing in the sandbox when I last looked at it. <div> </div> <div>I suggest we do all of this in GitHub, under let's say a 3.7 branch of <a href="http://github.com/jython/jython" target="_blank">github.com/jython/jython</a>. We can start by stripping out binaries - the jython.exe and everything in extlibs/ It's easy enough to retrieve from maven the necessary libraries, and it would be much better to have this be anything but something hardcoded going forward.</div> </div> <div class="gmail_extra"> <div class="gmail_quote">On Thu, Nov 23, 2017 at 4:34 PM, Jeff Allen <span><<a href="mailto:ja...@fa..." onclick="parent.window.location.href='ja...@fa...'; return false;" target="_blank">ja...@fa...</a>></span> wrote: <blockquote class="gmail_quote" style="margin: 0 0 0 0.8ex;border-left: 1.0px rgb(204,204,204) solid;padding-left: 1.0ex;"> <div> <p>(Starting a new thread for this.)</p> <p>Stefan:</p> <p>It is a good reminder that the repository in question is described as a "sandbox". It's largely un-reviewed work, outside the official repository. However, there's quite a lot of sand in the box.</p> <p>What you propose sounds good to me. So the idea is a branch from Jython 2.7.2. I am visualising this in GitHub. Do you imagine we would have moved 2.7 work to GitHub first? Or does the plan work while we are still mastered at <a href="http://hg.python.org" target="_blank">hg.python.org</a> and feeding a 2.7 branch that way?</p> <p>I couldn't imagine the mechanics when first I considered it, but have more knowledge of git now. The fusing of our dev guide back into a fork of the CPython dev guide is perhaps a microcosm and was good training.</p> <p>All the work I've done on Jython has been driven by Python regression tests, although the proportion of failures has always been fairly small. Do you think it would work to begin by adding the tests for Python 3.7 (or maybe aim a little lower), and repeatedly throwing ourselves at that rock face? The tests of course would fail massively at first. Or are they all only useful once Jython 3 works 80%?</p> <p>As when we discussed this previously, though, I'm unable to imagine an automated process for merging change, unless "automated" encompasses long hours spent with KDiff3. When you've nearly-bulk replaced PyString with PyUnicode, for example, how is *any* merge going to run smoothly?</p> Jeff<br/> <br/> <div class="m_-4740183061243169111moz-cite-prefix">On 23/11/2017 19:01, Stefan Richthofer wrote:</div> <blockquote> <div style="font-family: Verdana;font-size: 12.0px;"> <div> <div>> Merging means pulling from 2.7 to 3, I think.</div> <div> </div> <div>I'm actually going to try it the other way round.</div> <div> </div> <div>The current situation with Jython 3 concerns me a bit. It seems to</div> <div>be in a state where it is unclear how to proceed. This makes it</div> <div>somewhat discouraging to work on it. So I think we need a proper</div> <div>plan how to go on. I'd suggest the following:</div> <div> </div> <div>We open a new fresh Jython 3 that starts at Jython 2.7.2 release.</div> <div>Keep in mind that the Jython 3 repository is actually a *sandbox*</div> <div>so far. We merge every commit done to Jython 3 sandbox since it</div> <div>was forked from 2.7, (hopefully mainly via automatic merge</div> <div>mechanism). This is the ideal opportunity to triage the issue</div> <div>with broken Windows support and to review Isaiahs work. While</div> <div>he did a lot great work on Jython 3 we must keep in mind that it</div> <div>has been hardly reviewed so far.</div> <div>I hope we can end up with a workable Jython 3 containing all the</div> <div>bugfixes and improvements that were added in Jython 2.7.1 and 2.</div> <div>Problematic commits can be sorted out for later additional review.</div> <div> </div> <div>Regarding some aspects I propose to directly target Python 3.7, e.g.</div> <div>bytecode level and language syntax. Going through intermediate</div> <div>versions would be multiple work here.</div> <div> </div> <div>Besides this merging work we will need a real roadmap that states</div> <div>all the milestones and steps required for a Jython 3 release. Who</div> <div>of us knows Python well enough to put this together? Jim? Frank?</div> <div> </div> <div>After merging is done we need a clear policy about backporting etc.</div> <div>I'd suggest to focus on Jython 3 then and only backport crucial or</div> <div>cherry-picked bugfixed to 2.7 branch.</div> <div> </div> <div>In the sprint I'll start an inofficial experimental Jython 3 to work on merging.</div> <div>This can maybe form the basis for an official non-sandbox Jython 3.</div> <div> </div> <div>Thoughts?</div> <div> </div> <div> </div> <div>-Stefan</div> <div> </div> </div> </div> </blockquote> </div> <br/> ------------------------------------------------------------------------------<br/> Check out the vibrant tech community on one of the world's most<br/> engaging tech sites, <a href="http://Slashdot.org" target="_blank">Slashdot.org</a>! <a href="http://sdm.link/slashdot" target="_blank">http://sdm.link/slashdot</a><br/> _______________________________________________<br/> Jython-dev mailing list<br/> <a href="mailto:Jyt...@li..." onclick="parent.window.location.href='Jyt...@li...'; return false;" target="_blank">Jyt...@li...</a><br/> <a href="https://lists.sourceforge.net/lists/listinfo/jython-dev" target="_blank">https://lists.sourceforge.net/lists/listinfo/jython-dev</a><br/> </blockquote> </div> </div> </div> </blockquote> <blockquote> <div><span>------------------------------------------------------------------------------</span><br/> <span>Check out the vibrant tech community on one of the world's most</span><br/> <span>engaging tech sites, <a href="http://Slashdot.org" target="_blank">Slashdot.org</a>! <a href="http://sdm.link/slashdot" target="_blank">http://sdm.link/slashdot</a></span></div> </blockquote> <blockquote> <div><span>_______________________________________________</span><br/> <span>Jython-dev mailing list</span><br/> <span><a href="mailto:Jyt...@li..." onclick="parent.window.location.href='Jyt...@li...'; return false;" target="_blank">Jyt...@li...</a></span><br/> <span><a href="https://lists.sourceforge.net/lists/listinfo/jython-dev" target="_blank">https://lists.sourceforge.net/lists/listinfo/jython-dev</a></span></div> </blockquote> </div> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! <a href="http://sdm.link/slashdot_______________________________________________" target="_blank">http://sdm.link/slashdot_______________________________________________</a> Jython-dev mailing list Jyt...@li... <a href="https://lists.sourceforge.net/lists/listinfo/jython-dev" target="_blank">https://lists.sourceforge.net/lists/listinfo/jython-dev</a></div> </div> </div> </div> </div></div></body></html> |
|
From: Adam B. <ada...@gm...> - 2017-11-24 13:07:06
|
From the sidelines: Are there any meaningful subsets of 3.7 features / testpack which could make usable intermediate milestones? Cheers Adam > 在 2017年11月24日，上午9:44，Jim Baker <jim...@py...> 写道： > > I like the idea of starting from 2.7.2, and reaching back to the jython3 sandbox as it makes sense. One logical commit, followed by another, with tests passing as we converge on 3.7 (I assume it's easier to just target that version). The biggest immediate challenge will probably be around importlib logic, this is what is failing in the sandbox when I last looked at it. > > I suggest we do all of this in GitHub, under let's say a 3.7 branch of github.com/jython/jython. We can start by stripping out binaries - the jython.exe and everything in extlibs/ It's easy enough to retrieve from maven the necessary libraries, and it would be much better to have this be anything but something hardcoded going forward. > >> On Thu, Nov 23, 2017 at 4:34 PM, Jeff Allen <ja...@fa...> wrote: >> (Starting a new thread for this.) >> Stefan: >> >> It is a good reminder that the repository in question is described as a "sandbox". It's largely un-reviewed work, outside the official repository. However, there's quite a lot of sand in the box. >> What you propose sounds good to me. So the idea is a branch from Jython 2.7.2. I am visualising this in GitHub. Do you imagine we would have moved 2.7 work to GitHub first? Or does the plan work while we are still mastered at hg.python.org and feeding a 2.7 branch that way? >> I couldn't imagine the mechanics when first I considered it, but have more knowledge of git now. The fusing of our dev guide back into a fork of the CPython dev guide is perhaps a microcosm and was good training. >> All the work I've done on Jython has been driven by Python regression tests, although the proportion of failures has always been fairly small. Do you think it would work to begin by adding the tests for Python 3.7 (or maybe aim a little lower), and repeatedly throwing ourselves at that rock face? The tests of course would fail massively at first. Or are they all only useful once Jython 3 works 80%? >> As when we discussed this previously, though, I'm unable to imagine an automated process for merging change, unless "automated" encompasses long hours spent with KDiff3. When you've nearly-bulk replaced PyString with PyUnicode, for example, how is *any* merge going to run smoothly? >> Jeff >> >> >>> On 23/11/2017 19:01, Stefan Richthofer wrote: >>> > Merging means pulling from 2.7 to 3, I think. >>> >>> I'm actually going to try it the other way round. >>> >>> The current situation with Jython 3 concerns me a bit. It seems to >>> be in a state where it is unclear how to proceed. This makes it >>> somewhat discouraging to work on it. So I think we need a proper >>> plan how to go on. I'd suggest the following: >>> >>> We open a new fresh Jython 3 that starts at Jython 2.7.2 release. >>> Keep in mind that the Jython 3 repository is actually a *sandbox* >>> so far. We merge every commit done to Jython 3 sandbox since it >>> was forked from 2.7, (hopefully mainly via automatic merge >>> mechanism). This is the ideal opportunity to triage the issue >>> with broken Windows support and to review Isaiahs work. While >>> he did a lot great work on Jython 3 we must keep in mind that it >>> has been hardly reviewed so far. >>> I hope we can end up with a workable Jython 3 containing all the >>> bugfixes and improvements that were added in Jython 2.7.1 and 2. >>> Problematic commits can be sorted out for later additional review. >>> >>> Regarding some aspects I propose to directly target Python 3.7, e.g. >>> bytecode level and language syntax. Going through intermediate >>> versions would be multiple work here. >>> >>> Besides this merging work we will need a real roadmap that states >>> all the milestones and steps required for a Jython 3 release. Who >>> of us knows Python well enough to put this together? Jim? Frank? >>> >>> After merging is done we need a clear policy about backporting etc. >>> I'd suggest to focus on Jython 3 then and only backport crucial or >>> cherry-picked bugfixed to 2.7 branch. >>> >>> In the sprint I'll start an inofficial experimental Jython 3 to work on merging. >>> This can maybe form the basis for an official non-sandbox Jython 3. >>> >>> Thoughts? >>> >>> >>> -Stefan >>> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
|
From: Jim B. <jim...@py...> - 2017-11-24 01:45:22
|
I like the idea of starting from 2.7.2, and reaching back to the jython3 sandbox as it makes sense. One logical commit, followed by another, with tests passing as we converge on 3.7 (I assume it's easier to just target that version). The biggest immediate challenge will probably be around importlib logic, this is what is failing in the sandbox when I last looked at it. I suggest we do all of this in GitHub, under let's say a 3.7 branch of github.com/jython/jython. We can start by stripping out binaries - the jython.exe and everything in extlibs/ It's easy enough to retrieve from maven the necessary libraries, and it would be much better to have this be anything but something hardcoded going forward. On Thu, Nov 23, 2017 at 4:34 PM, Jeff Allen <ja...@fa...> wrote: > (Starting a new thread for this.) > > Stefan: > > It is a good reminder that the repository in question is described as a > "sandbox". It's largely un-reviewed work, outside the official repository. > However, there's quite a lot of sand in the box. > > What you propose sounds good to me. So the idea is a branch from Jython > 2.7.2. I am visualising this in GitHub. Do you imagine we would have moved > 2.7 work to GitHub first? Or does the plan work while we are still mastered > at hg.python.org and feeding a 2.7 branch that way? > > I couldn't imagine the mechanics when first I considered it, but have more > knowledge of git now. The fusing of our dev guide back into a fork of the > CPython dev guide is perhaps a microcosm and was good training. > > All the work I've done on Jython has been driven by Python regression > tests, although the proportion of failures has always been fairly small. Do > you think it would work to begin by adding the tests for Python 3.7 (or > maybe aim a little lower), and repeatedly throwing ourselves at that rock > face? The tests of course would fail massively at first. Or are they all > only useful once Jython 3 works 80%? > > As when we discussed this previously, though, I'm unable to imagine an > automated process for merging change, unless "automated" encompasses long > hours spent with KDiff3. When you've nearly-bulk replaced PyString with > PyUnicode, for example, how is *any* merge going to run smoothly? > Jeff > > > On 23/11/2017 19:01, Stefan Richthofer wrote: > > > Merging means pulling from 2.7 to 3, I think. > > I'm actually going to try it the other way round. > > The current situation with Jython 3 concerns me a bit. It seems to > be in a state where it is unclear how to proceed. This makes it > somewhat discouraging to work on it. So I think we need a proper > plan how to go on. I'd suggest the following: > > We open a new fresh Jython 3 that starts at Jython 2.7.2 release. > Keep in mind that the Jython 3 repository is actually a *sandbox* > so far. We merge every commit done to Jython 3 sandbox since it > was forked from 2.7, (hopefully mainly via automatic merge > mechanism). This is the ideal opportunity to triage the issue > with broken Windows support and to review Isaiahs work. While > he did a lot great work on Jython 3 we must keep in mind that it > has been hardly reviewed so far. > I hope we can end up with a workable Jython 3 containing all the > bugfixes and improvements that were added in Jython 2.7.1 and 2. > Problematic commits can be sorted out for later additional review. > > Regarding some aspects I propose to directly target Python 3.7, e.g. > bytecode level and language syntax. Going through intermediate > versions would be multiple work here. > > Besides this merging work we will need a real roadmap that states > all the milestones and steps required for a Jython 3 release. Who > of us knows Python well enough to put this together? Jim? Frank? > > After merging is done we need a clear policy about backporting etc. > I'd suggest to focus on Jython 3 then and only backport crucial or > cherry-picked bugfixed to 2.7 branch. > > In the sprint I'll start an inofficial experimental Jython 3 to work on > merging. > This can maybe form the basis for an official non-sandbox Jython 3. > > Thoughts? > > > -Stefan > > > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > > |
|
From: Jeff A. <ja...@fa...> - 2017-11-23 23:34:57
|
(Starting a new thread for this.) Stefan: It is a good reminder that the repository in question is described as a "sandbox". It's largely un-reviewed work, outside the official repository. However, there's quite a lot of sand in the box. What you propose sounds good to me. So the idea is a branch from Jython 2.7.2. I am visualising this in GitHub. Do you imagine we would have moved 2.7 work to GitHub first? Or does the plan work while we are still mastered at hg.python.org and feeding a 2.7 branch that way? I couldn't imagine the mechanics when first I considered it, but have more knowledge of git now. The fusing of our dev guide back into a fork of the CPython dev guide is perhaps a microcosm and was good training. All the work I've done on Jython has been driven by Python regression tests, although the proportion of failures has always been fairly small. Do you think it would work to begin by adding the tests for Python 3.7 (or maybe aim a little lower), and repeatedly throwing ourselves at that rock face? The tests of course would fail massively at first. Or are they all only useful once Jython 3 works 80%? As when we discussed this previously, though, I'm unable to imagine an automated process for merging change, unless "automated" encompasses long hours spent with KDiff3. When you've nearly-bulk replaced PyString with PyUnicode, for example, how is *any* merge going to run smoothly? Jeff On 23/11/2017 19:01, Stefan Richthofer wrote: > > Merging means pulling from 2.7 to 3, I think. > I'm actually going to try it the other way round. > The current situation with Jython 3 concerns me a bit. It seems to > be in a state where it is unclear how to proceed. This makes it > somewhat discouraging to work on it. So I think we need a proper > plan how to go on. I'd suggest the following: > We open a new fresh Jython 3 that starts at Jython 2.7.2 release. > Keep in mind that the Jython 3 repository is actually a *sandbox* > so far. We merge every commit done to Jython 3 sandbox since it > was forked from 2.7, (hopefully mainly via automatic merge > mechanism). This is the ideal opportunity to triage the issue > with broken Windows support and to review Isaiahs work. While > he did a lot great work on Jython 3 we must keep in mind that it > has been hardly reviewed so far. > I hope we can end up with a workable Jython 3 containing all the > bugfixes and improvements that were added in Jython 2.7.1 and 2. > Problematic commits can be sorted out for later additional review. > Regarding some aspects I propose to directly target Python 3.7, e.g. > bytecode level and language syntax. Going through intermediate > versions would be multiple work here. > Besides this merging work we will need a real roadmap that states > all the milestones and steps required for a Jython 3 release. Who > of us knows Python well enough to put this together? Jim? Frank? > After merging is done we need a clear policy about backporting etc. > I'd suggest to focus on Jython 3 then and only backport crucial or > cherry-picked bugfixed to 2.7 branch. > In the sprint I'll start an inofficial experimental Jython 3 to work > on merging. > This can maybe form the basis for an official non-sandbox Jython 3. > Thoughts? > -Stefan |
|
From: Stefan R. <Ste...@gm...> - 2017-11-23 19:01:34
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>> Merging means pulling from 2.7 to 3, I think.</div> <div> </div> <div>I'm actually going to try it the other way round.</div> <div> </div> <div>The current situation with Jython 3 concerns me a bit. It seems to</div> <div>be in a state where it is unclear how to proceed. This makes it</div> <div>somewhat discouraging to work on it. So I think we need a proper</div> <div>plan how to go on. I'd suggest the following:</div> <div> </div> <div>We open a new fresh Jython 3 that starts at Jython 2.7.2 release.</div> <div>Keep in mind that the Jython 3 repository is actually a *sandbox*</div> <div>so far. We merge every commit done to Jython 3 sandbox since it</div> <div>was forked from 2.7, (hopefully mainly via automatic merge</div> <div>mechanism). This is the ideal opportunity to triage the issue</div> <div>with broken Windows support and to review Isaiahs work. While</div> <div>he did a lot great work on Jython 3 we must keep in mind that it</div> <div>has been hardly reviewed so far.</div> <div>I hope we can end up with a workable Jython 3 containing all the</div> <div>bugfixes and improvements that were added in Jython 2.7.1 and 2.</div> <div>Problematic commits can be sorted out for later additional review.</div> <div> </div> <div>Regarding some aspects I propose to directly target Python 3.7, e.g.</div> <div>bytecode level and language syntax. Going through intermediate</div> <div>versions would be multiple work here.</div> <div> </div> <div>Besides this merging work we will need a real roadmap that states</div> <div>all the milestones and steps required for a Jython 3 release. Who</div> <div>of us knows Python well enough to put this together? Jim? Frank?</div> <div> </div> <div>After merging is done we need a clear policy about backporting etc.</div> <div>I'd suggest to focus on Jython 3 then and only backport crucial or</div> <div>cherry-picked bugfixed to 2.7 branch.</div> <div> </div> <div>In the sprint I'll start an inofficial experimental Jython 3 to work on merging.</div> <div>This can maybe form the basis for an official non-sandbox Jython 3.</div> <div> </div> <div>Thoughts?</div> <div> </div> <div> </div> <div>-Stefan</div> <div> </div> <div> </div> <div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Gesendet:</b> Donnerstag, 23. November 2017 um 19:03 Uhr<br/> <b>Von:</b> "Jeff Allen" <ja...@fa...><br/> <b>An:</b> "Stefan Richthofer" <Ste...@gm...><br/> <b>Betreff:</b> Re: [Jython-dev] Jython sprint, 25th and 26th of November, Düsseldorf, Germany</div> <div name="quoted-content"> <div style="background-color: rgb(255,255,255);"> <p>Good initiative, but too far for me. :) I will be working on Jython in some way this weekend, of course.</p> <p>Merging means pulling from 2.7 to 3, I think. Putting them in the same repository, as two branches, ought not to be a problem, but doesn't achieve much.</p> <p>Working productively with 3 has defeated me so far, as Isaiah's changes broke it for Windows and I've not figured out recreate the lumps of binary where it broke. (Also I think that approach is a tactical error for us.) I think maybe a sort of zip-fastener approach is needed working from the point of divergence, simulating a process that might have happened along the way.</p> Jeff<br/> <pre class="moz-signature">Jeff Allen </pre> <div class="moz-cite-prefix">On 22/11/2017 15:34, Stefan Richthofer wrote:</div> <blockquote> <pre>Dear Jython developers and users, Next weekend is another Python sprint by "Python Meeting Düsseldorf", <a class="moz-txt-link-freetext" href="https://www.meetup.com/Python-Meeting-Dusseldorf/events/243737124/" target="_blank">https://www.meetup.com/Python-Meeting-Dusseldorf/events/243737124/</a>. (25th and 26th of November in Düsseldorf, Germany) I'll be offering a sprint on Jython there. More specifically I hope we can look into merging Jython 2.7 trunk and Jython 3 sandbox. I'm aware that hardly anyone from this list can make it there in person (if so, even better!), but please feel encouraged to participate remotely via Jython's IRC-channel irc://irc.freenode.net/#jython. We will be online there 11.00-17.30 CET each day (and hopefully fill it with more activity than usual). Potential topics include: Using Jython: - Jython basics / getting started - Python/Java integration (e.g. calling Java from Python and vice versa) - scripting Java with Jython - GUI with JavaFX in Python Developing Jython: - Jython internals / getting started - Bugfixes in Jython core - Can we fix some actual bugs? (I will especially look into current release blockers <a class="moz-txt-link-freetext" href="http://bugs.jython.org/issue2487" target="_blank">http://bugs.jython.org/issue2487</a> and <a class="moz-txt-link-freetext" href="http://bugs.jython.org/issue2570" target="_blank">http://bugs.jython.org/issue2570</a>) - Merging Jython 2.7 trunk and Jython 3 sandbox Experimental stuff (What is already workable? Let's try!): - JyNI (e.g. NumPy, ctypes) - Jython 3 Individual stuff: - You have some project or usecase for Jython and need advice? - There is some specific gap keeping you from using Jython? -- Maybe we can fix it or work around. -- Maybe even if it involves a C-Extension (let's tweak JyNI) Looking forward to work with you! -Stefan ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! <a class="moz-txt-link-freetext" href="http://sdm.link/slashdot" target="_blank">http://sdm.link/slashdot</a> _______________________________________________ Jython-dev mailing list <a class="moz-txt-link-abbreviated" href="mailto:Jyt...@li..." onclick="parent.window.location.href='Jyt...@li...'; return false;" target="_blank">Jyt...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/jython-dev" target="_blank">https://lists.sourceforge.net/lists/listinfo/jython-dev</a> </pre> </blockquote> </div> </div> </div> </div> </div></div></body></html> |
|
From: <fwi...@gm...> - 2017-11-22 22:18:13
|
Hi Jeff,
That looks right except (as you where guessing) jython.version should be:
<property name="jython.version" value="2.7.2a1+"/>
The plus is a convention copied from CPython that I'm pretty sure
means that this is still in development and is not the tagged 2.7.2a1.
The reason we have a "noplus" version if I'm remembering correctly is
that the + doesn't work as part of a name for the maven packages.
As for tagging:
I think I'm the only one with the permissions on maven to actually
push a package, though I'm happy to share the responsibility :) -- let
me know and I will look into how you get those rights if you want
them. I think anyone can tag a release, but it probably makes sense
for the person who pushes the release to be the same as the one who
tags it.
Thanks for moving this forward!
-Frank
On Wed, Nov 22, 2017 at 1:08 PM, Jeff Allen <ja...@fa...> wrote:
> Thanks Frank. 2nd or 27th Feb, perhaps.
>
> As you're the expert in this, can I ask am I doing this right (in build.xml,
> obviously):
>
> <!-- The current version info -->
> <property name="jython.version" value="2.7.2a1"/>
> <property name="jython.version.noplus" value="2.7.2a1"/>
> <property name="jython.major_version" value="2"/>
> <property name="jython.minor_version" value="7"/>
> <property name="jython.micro_version" value="2"/>
> <property name="jython.release_level"
> value="${PY_RELEASE_LEVEL_ALPHA}"/>
> <property name="jython.release_serial" value="1"/>
>
> In history, I see we commit this type of change, then there's a commit with
> a tag. Am I able to push a change that adds a tag? ISTR there's a
> restriction.
>
> When do we add the + to a version? (We seem to have forgotten so far in
> 2.7.1.) Does the plus have a magical effect somewhere?
>
> Jeff
>
> Jeff Allen
>
> On 22/11/2017 19:42, fwi...@gm... wrote:
>
> A new year's 2.7.2 with a limited scope is definitely a great idea, as
> is an updated GitHub based website. I'm on board!
>
> -Frank
>
> On Tue, Nov 21, 2017 at 3:32 PM, Jeff Allen <ja...@fa...> wrote:
>
> All:
>
> How about it? This seems like a reasonable interval since 2.7.1.
>
> Frank/Jim: would you care to set a goal? What else ought we to have in that
> release?
>
> I think we should mean by the answer, what we'd like to see in 2.7.2b1. Then
> we only take on fixes during beta we didn't foresee or can't avoid. That
> way, we hopefully don't stay in beta very long. I'm extrapolating a bit from
> https://github.com/jython/devguide/blob/jython/devcycle.rst#stages (cloned
> from CPython) but it seems a good discipline to prevent late de-stabilising
> change.
>
> Is it perhaps as important to create a revised web site to back the release?
> (We have talked about a site we can all contribute to via GitHub.)
>
> Also, I've been meaning to ask, the current dev tip should identify as
> "2.7.1+" (not plain "2.7.1") shouldn't it? And 2.7.2a1 then 2.7.2a1+ as soon
> as we decide we're having a 2.7.2? I think I see how this works in
> build.xml.
>
> Jeff
>
> --
> Jeff Allen
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>
|
101 messages has been excluded from this view by a project administrator.
