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
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Rory O'D. <ror...@or...> - 2020-06-22 15:35:15
|
Hi Alan,
*Per the JDK 15 schedule , we are in Rampdown Phase One* *[1] *
*Please advise if you find any issues while testing the latest Early
Access builds.
*
* Schedule for JDK 15
o *2020/06/11 Rampdown Phase One*
o 2020/07/16 Rampdown Phase Two
o 2020/08/06 Initial Release Candidate
o 2020/08/20 Final Release Candidate
o 2020/09/15 General Availability
* Features included in JDK 15:
o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
<http://openjdk.java.net/jeps/339>
o JEP 360: Sealed Classes (Preview) <http://openjdk.java.net/jeps/360>
o JEP 371: Hidden Classes <http://openjdk.java.net/jeps/371>
o JEP 372: Remove the Nashorn JavaScript Engine
<http://openjdk.java.net/jeps/372>
o JEP 373: Reimplement the Legacy DatagramSocket API
<https://openjdk.java.net/jeps/373>
o JEP 374: Disable and Deprecate Biased Locking
<http://openjdk.java.net/jeps/374>
o JEP 375: Pattern Matching for instanceof (Second Preview)
<https://openjdk.java.net/jeps/375>
o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
<http://openjdk.java.net/jeps/377>
o JEP 378: Text Blocks <http://openjdk.java.net/jeps/378>
o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
<https://openjdk.java.net/jeps/379>
o JEP 381: Remove the Solaris and SPARC Ports
<https://openjdk.java.net/jeps/381>
o JEP 383: Foreign-Memory Access API (Second Incubator)
<https://openjdk.java.net/jeps/383>
o JEP 384: Records (Second Preview)
<https://openjdk.java.net/jeps/384>
o JEP 385: Deprecate RMI Activation for Removal
<https://openjdk.java.net/jeps/385>
*JDK 15 **Early Access build 28 **is available**at : - jdk.java.net/15/*
These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception**Release
notes
* Release notes
o http://jdk.java.net/15/release-notes
* Recent fixes that might be of interest
o Build 27
+ JDK-8233215: jpackage doesn't allow enough flexibility for
file type binding
+ JDK-8244582: Remove terminally deprecated Solaris-specific
SO_FLOW_SLA socket option
+ JDK-8245068: Implement Deprecation of RMI Activation
+ JDK-8246770: Atomic::add() with 64 bit value fails to link
on 32-bit platforms
# Reported by JaCoCo
o Build 26
+ JDK-8240871: SSLEngine handshake status immediately after
the handshake can be NOT_HANDSHAKING rather than FINISHED
with TLSv1.3
# Reported by Apache Tomcat
o Build 25
+ JDK-8206925: Support the certificate_authorities extension
+ JDK-8239480: Support for CLDR version 37
+ JDK-8243925: Toolkit#getScreenInsets() returns wrong value
on HiDPI screens (Windows)
*JDK 16 Early Access build 2 ****is available**at : - jdk.java.net/16/*
These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception.*
*
*_Survey on _**_jinfo, jmap, jstack serviceability tools in JDK:_ *
* Oracle is considering deprecation and (eventual) removal of 3 JDK
tools - jinfo, jmap, jstack.
* The Survey Link
<https://www.questionpro.com/a/TakeSurvey?tt=n%2BDcx/aY3aA%3D> will
remain open through July 15 2020.
Rgds, Rory
[1] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-June/004401.html
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
|
|
From: Jython t. <st...@bu...> - 2020-06-19 18:05:36
|
ACTIVITY SUMMARY (2020-06-12 - 2020-06-19) Jython tracker at https://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 346 ( +0) closed 2484 ( +0) total 2830 ( +0) Open issues with patches: 22 Most recent 15 issues with no replies (15) ========================================== #2898: Fix serialization format https://bugs.jython.org/issue2898 #2886: doing relative imports in a loop causes bad performance due to https://bugs.jython.org/issue2886 #2882: A cmd.exe in the CWD will be executed unexpectedly https://bugs.jython.org/issue2882 #2878: java.lang.OutOfMemoryError: Java heap space https://bugs.jython.org/issue2878 #2876: NullPointer exception PyModule.java https://bugs.jython.org/issue2876 #2874: Jython 2.7 is not able to import an EBCDIC file on z/OS https://bugs.jython.org/issue2874 #2866: Interface default methods disregarded by the method resolver https://bugs.jython.org/issue2866 #2864: Importing second instance of httplib causes an error https://bugs.jython.org/issue2864 #2854: from module import * leads to wild goose chase https://bugs.jython.org/issue2854 #2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows https://bugs.jython.org/issue2798 #2794: invocation_tests.py missing from modjy tests https://bugs.jython.org/issue2794 #2792: Failures in test_import_jy from Java 13 https://bugs.jython.org/issue2792 #2790: Equivalent signal handlers do not test equal using == https://bugs.jython.org/issue2790 #2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7 https://bugs.jython.org/issue2770 #2760: How to call procedure with use zxjdbc and get back OUT paramet https://bugs.jython.org/issue2760 Most recent 15 issues waiting for review (15) ============================================= #2566: inspect does not recognize code objects from bytecode files https://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules https://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the https://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses https://bugs.jython.org/issue2367 #2363: relative seeks works incorrectly after readline https://bugs.jython.org/issue2363 #2143: site-packages support in standalone jar https://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context https://bugs.jython.org/issue2142 #1925: Support loading java.sql.Drivers that aren't on the boot class https://bugs.jython.org/issue1925 #1917: No ctypes.c_char https://bugs.jython.org/issue1917 #1842: Add IBM i support to Jython https://bugs.jython.org/issue1842 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo https://bugs.jython.org/issue1741 #1646: Proxy getInterface not change for more PyObject https://bugs.jython.org/issue1646 #1612: array.array should use specialized bulk operations to initiali https://bugs.jython.org/issue1612 #1435: traceback doesn't include Java stack trace in user functions https://bugs.jython.org/issue1435 #1336: PyDeque should likely subclass PySequence https://bugs.jython.org/issue1336 |
|
From: Jython t. <st...@bu...> - 2020-06-12 18:05:40
|
ACTIVITY SUMMARY (2020-06-05 - 2020-06-12) Jython tracker at https://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 346 ( +0) closed 2484 ( +0) total 2830 ( +0) Open issues with patches: 22 Most recent 15 issues with no replies (15) ========================================== #2898: Fix serialization format https://bugs.jython.org/issue2898 #2886: doing relative imports in a loop causes bad performance due to https://bugs.jython.org/issue2886 #2882: A cmd.exe in the CWD will be executed unexpectedly https://bugs.jython.org/issue2882 #2878: java.lang.OutOfMemoryError: Java heap space https://bugs.jython.org/issue2878 #2876: NullPointer exception PyModule.java https://bugs.jython.org/issue2876 #2874: Jython 2.7 is not able to import an EBCDIC file on z/OS https://bugs.jython.org/issue2874 #2866: Interface default methods disregarded by the method resolver https://bugs.jython.org/issue2866 #2864: Importing second instance of httplib causes an error https://bugs.jython.org/issue2864 #2854: from module import * leads to wild goose chase https://bugs.jython.org/issue2854 #2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows https://bugs.jython.org/issue2798 #2794: invocation_tests.py missing from modjy tests https://bugs.jython.org/issue2794 #2792: Failures in test_import_jy from Java 13 https://bugs.jython.org/issue2792 #2790: Equivalent signal handlers do not test equal using == https://bugs.jython.org/issue2790 #2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7 https://bugs.jython.org/issue2770 #2760: How to call procedure with use zxjdbc and get back OUT paramet https://bugs.jython.org/issue2760 Most recent 15 issues waiting for review (15) ============================================= #2566: inspect does not recognize code objects from bytecode files https://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules https://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the https://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses https://bugs.jython.org/issue2367 #2363: relative seeks works incorrectly after readline https://bugs.jython.org/issue2363 #2143: site-packages support in standalone jar https://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context https://bugs.jython.org/issue2142 #1925: Support loading java.sql.Drivers that aren't on the boot class https://bugs.jython.org/issue1925 #1917: No ctypes.c_char https://bugs.jython.org/issue1917 #1842: Add IBM i support to Jython https://bugs.jython.org/issue1842 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo https://bugs.jython.org/issue1741 #1646: Proxy getInterface not change for more PyObject https://bugs.jython.org/issue1646 #1612: array.array should use specialized bulk operations to initiali https://bugs.jython.org/issue1612 #1435: traceback doesn't include Java stack trace in user functions https://bugs.jython.org/issue1435 #1336: PyDeque should likely subclass PySequence https://bugs.jython.org/issue1336 |
|
From: Jeff A. <ja...@fa...> - 2020-06-12 06:03:02
|
Thanks for testing in your environment. That's a good reassurance I haven't made a dud. Presumably it now also signs on with a sensible sensible change set reference, instead of just grumbling about being an uncontrolled copy. (ISTR you used to see that when working git-based. We've caught up with you.) I think we should say jython/jython is open for business. Anyone have misgivings? Jeff Jeff Allen On 11/06/2020 07:34, Adam Burke wrote: > Basic test drives and sanity tests worked for me: > > + cloned new repo on a new (windows) machine > + built from ant > + ran gradle but got a deprecation warning which seems to be the > current state > + spun up the console, did a few simple things > + ran system tests and got current expected state > > 7 tests skipped: > test_codecmaps_hk test_curses test_smtpnet test_socketserver > test_subprocess test_urllib2net test_urllibnet > 0 tests failed: > > Platform: > 'Java-13.0.2-OpenJDK_64-Bit_Server_VM,_13.0.2+8,_Oracle_Corporation-on-Windows_10-10.0-amd64' > Command line: > ['C:\\Users\\burkeat\\jython\\jython1\\jython\\dist\\Lib\\test\\regrtest.py', > '-e', '-m', 'regrtest_memo.txt'] > > Cheers > Adam > > On Fri, 5 Jun 2020 at 17:55, Jeff Allen <ja...@fa... > <mailto:ja...@fa...>> wrote: > > Welcome to your new home: https://github.com/jython/jython > > Take a look around. I'm sincerely hoping this works for us all, or > is only wrong in ways we can put right. If you find this is > irreparably messed up, we may be able to start over. Otherwise, I > think this is where we now invite contribution and fix issues. > > After a day or two cooling off, I propse we ask the Ernest and the > infrastructure team to make hg.python.org/jython > <http://hg.python.org/jython> read-only in some gentle way we > could reverse if we had to. > > Anything other loose ends? > > Jeff > > Jeff Allen > > On 25/05/2020 16:42, Jeff Allen wrote: >> We've wanted to do this for ages. If you go back far enough, you >> can find Jim confidently asserting we'd use GitHub for 2.7.2 >> (https://sourceforge.net/p/jython/mailman/jython-dev/thread/CAOhO%3DaO_4GruQXQqmZk39a0C%3DXUnKyj%3DG6OcQtBkhtoQm9BCjw%40mail.gmail.com/#msg35054683). >> >> Building with Gradle and accessing dependencies remotely (no JARs >> checked in) were identified as prerequisites at the time. In >> turn, I think building with Gradle requires re-organising the >> code to fit with its /convention over configuration/ idea >> (https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). >> At least, doing otherwise in 2.7.2 got too difficult for me, >> somewhere around exposed classes ISTR. >> >> These don't seem to be prerequisites for the move. I would do >> Jython 3 that way, but leave 2.7.3 as it is. >> >> https://bugs.jython.org/issue2892 opened to cover this. I'll try, >> starting withthe obvious way >> (https://help.github.com/en/github/importing-your-projects-to-github/importing-a-repository-with-github-importer) >> and reading what CPython did. I'd be happy to take input from >> anyone with a sure-fire answer. >> > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > <mailto:Jyt...@li...> > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Adam B. <ada...@gm...> - 2020-06-11 06:34:57
|
Basic test drives and sanity tests worked for me:
+ cloned new repo on a new (windows) machine
+ built from ant
+ ran gradle but got a deprecation warning which seems to be the current
state
+ spun up the console, did a few simple things
+ ran system tests and got current expected state
7 tests skipped:
test_codecmaps_hk test_curses test_smtpnet test_socketserver
test_subprocess test_urllib2net test_urllibnet
0 tests failed:
Platform:
'Java-13.0.2-OpenJDK_64-Bit_Server_VM,_13.0.2+8,_Oracle_Corporation-on-Windows_10-10.0-amd64'
Command line:
['C:\\Users\\burkeat\\jython\\jython1\\jython\\dist\\Lib\\test\\regrtest.py',
'-e', '-m', 'regrtest_memo.txt']
Cheers
Adam
On Fri, 5 Jun 2020 at 17:55, Jeff Allen <ja...@fa...> wrote:
> Welcome to your new home: https://github.com/jython/jython
>
> Take a look around. I'm sincerely hoping this works for us all, or is only
> wrong in ways we can put right. If you find this is irreparably messed up,
> we may be able to start over. Otherwise, I think this is where we now
> invite contribution and fix issues.
>
> After a day or two cooling off, I propse we ask the Ernest and the
> infrastructure team to make hg.python.org/jython read-only in some gentle
> way we could reverse if we had to.
>
> Anything other loose ends?
>
> Jeff
>
> Jeff Allen
>
> On 25/05/2020 16:42, Jeff Allen wrote:
>
> We've wanted to do this for ages. If you go back far enough, you can find
> Jim confidently asserting we'd use GitHub for 2.7.2 (
> https://sourceforge.net/p/jython/mailman/jython-dev/thread/CAOhO%3DaO_4GruQXQqmZk39a0C%3DXUnKyj%3DG6OcQtBkhtoQm9BCjw%40mail.gmail.com/#msg35054683
> ).
>
> Building with Gradle and accessing dependencies remotely (no JARs checked
> in) were identified as prerequisites at the time. In turn, I think building
> with Gradle requires re-organising the code to fit with its /convention
> over configuration/ idea (
> https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions).
> At least, doing otherwise in 2.7.2 got too difficult for me, somewhere
> around exposed classes ISTR.
>
> These don't seem to be prerequisites for the move. I would do Jython 3
> that way, but leave 2.7.3 as it is.
>
> https://bugs.jython.org/issue2892 opened to cover this. I'll try,
> starting withthe obvious way (
> https://help.github.com/en/github/importing-your-projects-to-github/importing-a-repository-with-github-importer)
> and reading what CPython did. I'd be happy to take input from anyone with a
> sure-fire answer.
>
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
|
|
From: Jython t. <st...@bu...> - 2020-06-05 18:05:59
|
ACTIVITY SUMMARY (2020-05-29 - 2020-06-05) Jython tracker at https://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 346 ( +2) closed 2484 ( +0) total 2830 ( +2) Open issues with patches: 22 Issues opened (2) ================= #2896: Jython's logger is split from everything else https://bugs.jython.org/issue2896 opened by doublep #2898: Fix serialization format https://bugs.jython.org/issue2898 opened by doublep Most recent 15 issues with no replies (15) ========================================== #2898: Fix serialization format https://bugs.jython.org/issue2898 #2886: doing relative imports in a loop causes bad performance due to https://bugs.jython.org/issue2886 #2882: A cmd.exe in the CWD will be executed unexpectedly https://bugs.jython.org/issue2882 #2878: java.lang.OutOfMemoryError: Java heap space https://bugs.jython.org/issue2878 #2876: NullPointer exception PyModule.java https://bugs.jython.org/issue2876 #2874: Jython 2.7 is not able to import an EBCDIC file on z/OS https://bugs.jython.org/issue2874 #2866: Interface default methods disregarded by the method resolver https://bugs.jython.org/issue2866 #2864: Importing second instance of httplib causes an error https://bugs.jython.org/issue2864 #2854: from module import * leads to wild goose chase https://bugs.jython.org/issue2854 #2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows https://bugs.jython.org/issue2798 #2794: invocation_tests.py missing from modjy tests https://bugs.jython.org/issue2794 #2792: Failures in test_import_jy from Java 13 https://bugs.jython.org/issue2792 #2790: Equivalent signal handlers do not test equal using == https://bugs.jython.org/issue2790 #2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7 https://bugs.jython.org/issue2770 #2760: How to call procedure with use zxjdbc and get back OUT paramet https://bugs.jython.org/issue2760 Most recent 15 issues waiting for review (15) ============================================= #2566: inspect does not recognize code objects from bytecode files https://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules https://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the https://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses https://bugs.jython.org/issue2367 #2363: relative seeks works incorrectly after readline https://bugs.jython.org/issue2363 #2143: site-packages support in standalone jar https://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context https://bugs.jython.org/issue2142 #1925: Support loading java.sql.Drivers that aren't on the boot class https://bugs.jython.org/issue1925 #1917: No ctypes.c_char https://bugs.jython.org/issue1917 #1842: Add IBM i support to Jython https://bugs.jython.org/issue1842 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo https://bugs.jython.org/issue1741 #1646: Proxy getInterface not change for more PyObject https://bugs.jython.org/issue1646 #1612: array.array should use specialized bulk operations to initiali https://bugs.jython.org/issue1612 #1435: traceback doesn't include Java stack trace in user functions https://bugs.jython.org/issue1435 #1336: PyDeque should likely subclass PySequence https://bugs.jython.org/issue1336 Top 10 most discussed issues (2) ================================ #2892: Migrate from hg.python.org to GitHub https://bugs.jython.org/issue2892 7 msgs #2896: Jython's logger is split from everything else https://bugs.jython.org/issue2896 4 msgs |
|
From: Jeff A. <ja...@fa...> - 2020-06-05 07:55:27
|
Welcome to your new home: https://github.com/jython/jython Take a look around. I'm sincerely hoping this works for us all, or is only wrong in ways we can put right. If you find this is irreparably messed up, we may be able to start over. Otherwise, I think this is where we now invite contribution and fix issues. After a day or two cooling off, I propse we ask the Ernest and the infrastructure team to make hg.python.org/jython read-only in some gentle way we could reverse if we had to. Anything other loose ends? Jeff Jeff Allen On 25/05/2020 16:42, Jeff Allen wrote: > We've wanted to do this for ages. If you go back far enough, you can > find Jim confidently asserting we'd use GitHub for 2.7.2 > (https://sourceforge.net/p/jython/mailman/jython-dev/thread/CAOhO%3DaO_4GruQXQqmZk39a0C%3DXUnKyj%3DG6OcQtBkhtoQm9BCjw%40mail.gmail.com/#msg35054683). > > Building with Gradle and accessing dependencies remotely (no JARs > checked in) were identified as prerequisites at the time. In turn, I > think building with Gradle requires re-organising the code to fit with > its /convention over configuration/ idea > (https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). > At least, doing otherwise in 2.7.2 got too difficult for me, somewhere > around exposed classes ISTR. > > These don't seem to be prerequisites for the move. I would do Jython 3 > that way, but leave 2.7.3 as it is. > > https://bugs.jython.org/issue2892 opened to cover this. I'll try, > starting withthe obvious way > (https://help.github.com/en/github/importing-your-projects-to-github/importing-a-repository-with-github-importer) > and reading what CPython did. I'd be happy to take input from anyone > with a sure-fire answer. > |
|
From: Jeff A. <ja...@fa...> - 2020-06-03 10:49:39
|
Ok, I seem to be ready so will try for real. Details on https://bugs.jython.org/issue2892 . I'll try today, but I think there is a fair amount of manual work to migrate issues/PRs. Some references will probably break. Jeff Allen |
|
From: Jeff A. <ja...@fa...> - 2020-06-02 12:23:29
|
On 26/05/2020 06:13, Jim Baker wrote: > On Mon, May 25, 2020 at 9:43 AM Jeff Allen <ja...@fa... > <mailto:ja...@fa...>> wrote: > For sure, we need to do this, under https://github.com/jython/jython > Ideally we would replace the Jython 3 sandbox > thttps://github.com/jython/jython3 with just a README that that points > to this historical work, but otherwise is empty. (If this were a > sandbox under someone's name I would keep as is, but under this name > we have to do this cleanup to avoid confusion.) I'm making reasonable progress in that direction and you can read the fun on https://bugs.jython.org/issue2892 . GitHub lets us make repositories private now. Is that a good answer? > One other thing we should consider in this move to GitHub is the > overall workflow. I suggest we switch over to GitHub issues, and > anything else accommodated by the GitHub ecosystem (eg > https://github.com/features/actions). So I wouldn't want to spend time > investing in implementing the full CPython workflow here like > Discourse - standard GitHub is more than adequate for our needs. Given > that Jython 3 will have effectively its own bugs, this can be a good > clean break with bugs.jython.org <http://bugs.jython.org> as it is - I > would keep around historically, but I wouldn't bother porting over > these possibly irrelevant issues into GitHub. However, we would need > to do something to ensure that bugs are not inadvertently reported > there - an advisory notice somewhere on that site should suffice. Definitely, when there is a Jython 3 to have bugs, we only want them in one place. CPython are keeping bugs.python.org around, but they've been maintaining it. It is still the basis of the PSF CLA process that covers us. (I'm quite keen to keep that.) Our bugs.jython.org is looking increasingly fragile, so I agree we should discourage reports there, but I think we'd accept them, and there are quite a few outstanding issues we probably need until Jython 2.7 is no longer maintained. Jeff |
|
From: Jython t. <st...@bu...> - 2020-05-29 18:06:03
|
ACTIVITY SUMMARY (2020-05-22 - 2020-05-29) Jython tracker at https://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 344 ( +2) closed 2484 ( +0) total 2828 ( +2) Open issues with patches: 22 Issues opened (2) ================= #2892: Migrate from hg.python.org to GitHub https://bugs.jython.org/issue2892 opened by jeff.allen #2894: urllib2 POST > 64k fails https://bugs.jython.org/issue2894 opened by gbach Most recent 15 issues with no replies (15) ========================================== #2886: doing relative imports in a loop causes bad performance due to https://bugs.jython.org/issue2886 #2882: A cmd.exe in the CWD will be executed unexpectedly https://bugs.jython.org/issue2882 #2878: java.lang.OutOfMemoryError: Java heap space https://bugs.jython.org/issue2878 #2876: NullPointer exception PyModule.java https://bugs.jython.org/issue2876 #2874: Jython 2.7 is not able to import an EBCDIC file on z/OS https://bugs.jython.org/issue2874 #2866: Interface default methods disregarded by the method resolver https://bugs.jython.org/issue2866 #2864: Importing second instance of httplib causes an error https://bugs.jython.org/issue2864 #2854: from module import * leads to wild goose chase https://bugs.jython.org/issue2854 #2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows https://bugs.jython.org/issue2798 #2794: invocation_tests.py missing from modjy tests https://bugs.jython.org/issue2794 #2792: Failures in test_import_jy from Java 13 https://bugs.jython.org/issue2792 #2790: Equivalent signal handlers do not test equal using == https://bugs.jython.org/issue2790 #2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7 https://bugs.jython.org/issue2770 #2760: How to call procedure with use zxjdbc and get back OUT paramet https://bugs.jython.org/issue2760 #2754: Failure in Py.initProxy for class not at module level https://bugs.jython.org/issue2754 Most recent 15 issues waiting for review (15) ============================================= #2566: inspect does not recognize code objects from bytecode files https://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules https://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the https://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses https://bugs.jython.org/issue2367 #2363: relative seeks works incorrectly after readline https://bugs.jython.org/issue2363 #2143: site-packages support in standalone jar https://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context https://bugs.jython.org/issue2142 #1925: Support loading java.sql.Drivers that aren't on the boot class https://bugs.jython.org/issue1925 #1917: No ctypes.c_char https://bugs.jython.org/issue1917 #1842: Add IBM i support to Jython https://bugs.jython.org/issue1842 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo https://bugs.jython.org/issue1741 #1646: Proxy getInterface not change for more PyObject https://bugs.jython.org/issue1646 #1612: array.array should use specialized bulk operations to initiali https://bugs.jython.org/issue1612 #1435: traceback doesn't include Java stack trace in user functions https://bugs.jython.org/issue1435 #1336: PyDeque should likely subclass PySequence https://bugs.jython.org/issue1336 |
|
From: Eero A. <eer...@ik...> - 2020-05-29 08:16:35
|
On Thu, May 28, 2020 at 10:14 PM Jeff Allen <ja...@fa...> wrote: > On 28/05/2020 13:13, Eero Aaltonen wrote: > > Regarding the jars, are you > * going to keep the history intact and the jars in the resulting Git > repository or > * a harsher break dropping the binaries completely? > > What we have (jars and all) will be on the 2.7 branch, where Gradle would > not go any further than I got with jython-slim. GitHub discourages large > binary files, and large repos generally, but we're not at the point where > it makes us use their large file store. > This will incur a cost when doing an initial clone of the repository, as Git will compress everything before transferring over the network. If you don't have heavy CI and generally keep existing clones, the cost should amortize reasonably. -- Eero Aaltonen > |
|
From: <fwi...@gm...> - 2020-05-28 23:56:03
|
On Mon, May 25, 2020 at 8:44 AM Jeff Allen <ja...@fa...> wrote: > We've wanted to do this for ages. If you go back far enough, you can > find Jim confidently asserting we'd use GitHub for 2.7.2 > ( > https://sourceforge.net/p/jython/mailman/jython-dev/thread/CAOhO%3DaO_4GruQXQqmZk39a0C%3DXUnKyj%3DG6OcQtBkhtoQm9BCjw%40mail.gmail.com/#msg35054683 > ). > > Building with Gradle and accessing dependencies remotely (no JARs > checked in) were identified as prerequisites at the time. In turn, I > think building with Gradle requires re-organising the code to fit with > its /convention over configuration/ idea > ( > https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). > > At least, doing otherwise in 2.7.2 got too difficult for me, somewhere > around exposed classes ISTR. > > These don't seem to be prerequisites for the move. I would do Jython 3 > that way, but leave 2.7.3 as it is. > > https://bugs.jython.org/issue2892 opened to cover this. I'll try, > starting withthe obvious way > ( > https://help.github.com/en/github/importing-your-projects-to-github/importing-a-repository-with-github-importer) > > and reading what CPython did. I'd be happy to take input from anyone > with a sure-fire answer. > Great news! -Frank |
|
From: Jeff A. <ja...@fa...> - 2020-05-28 19:14:25
|
On 28/05/2020 13:13, Eero Aaltonen wrote: > On Mon, May 25, 2020 at 6:43 PM Jeff Allen <ja...@fa... > <mailto:ja...@fa...>> wrote: > > Building with Gradle and accessing dependencies remotely (no JARs > checked in) were identified as prerequisites at the time. In turn, I > think building with Gradle requires re-organising the code to fit > with > its /convention over configuration/ idea > (https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). > > At least, doing otherwise in 2.7.2 got too difficult for me, > somewhere > around exposed classes ISTR. > > > Regarding the jars, are you > * going to keep the history intact and the jars in the resulting Git > repository or > * a harsher break dropping the binaries completely? What we have (jars and all) will be on the 2.7 branch, where Gradle would not go any further than I got with jython-slim. GitHub discourages large binary files, and large repos generally, but we're not at the point where it makes us use their large file store. I've been doing a project with just Gradle (and structured according to Gradle's liking, which was my point). I foresee a 3.8 branch built the same way and not using ant or checking in dependencies at all. Jeff Allen |
|
From: Eero A. <eer...@ik...> - 2020-05-28 12:13:36
|
On Mon, May 25, 2020 at 6:43 PM Jeff Allen <ja...@fa...> wrote: > Building with Gradle and accessing dependencies remotely (no JARs > checked in) were identified as prerequisites at the time. In turn, I > think building with Gradle requires re-organising the code to fit with > its /convention over configuration/ idea > ( > https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). > > At least, doing otherwise in 2.7.2 got too difficult for me, somewhere > around exposed classes ISTR. > Regarding the jars, are you * going to keep the history intact and the jars in the resulting Git repository or * a harsher break dropping the binaries completely? -- Eero Aaltonen |
|
From: Jim B. <jim...@py...> - 2020-05-26 00:33:00
|
On Mon, May 25, 2020 at 9:43 AM Jeff Allen <ja...@fa...> wrote: > We've wanted to do this for ages. If you go back far enough, you can > find Jim confidently asserting we'd use GitHub for 2.7.2 > ( > https://sourceforge.net/p/jython/mailman/jython-dev/thread/CAOhO%3DaO_4GruQXQqmZk39a0C%3DXUnKyj%3DG6OcQtBkhtoQm9BCjw%40mail.gmail.com/#msg35054683 > ). > Hah, yes, I had much more confidence back before we got stuck on some critical bugs finally resolved with the actual 2.7.2. > > Building with Gradle and accessing dependencies remotely (no JARs > checked in) were identified as prerequisites at the time. In turn, I > think building with Gradle requires re-organising the code to fit with > its /convention over configuration/ idea > ( > https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). > > At least, doing otherwise in 2.7.2 got too difficult for me, somewhere > around exposed classes ISTR. > +100 > > These don't seem to be prerequisites for the move. I would do Jython 3 > that way, but leave 2.7.3 as it is. > For sure, we need to do this, under https://github.com/jython/jython Ideally we would replace the Jython 3 sandbox t https://github.com/jython/jython3 with just a README that that points to this historical work, but otherwise is empty. (If this were a sandbox under someone's name I would keep as is, but under this name we have to do this cleanup to avoid confusion.) One other thing we should consider in this move to GitHub is the overall workflow. I suggest we switch over to GitHub issues, and anything else accommodated by the GitHub ecosystem (eg https://github.com/features/actions). So I wouldn't want to spend time investing in implementing the full CPython workflow here like Discourse - standard GitHub is more than adequate for our needs. Given that Jython 3 will have effectively its own bugs, this can be a good clean break with bugs.jython.org as it is - I would keep around historically, but I wouldn't bother porting over these possibly irrelevant issues into GitHub. However, we would need to do something to ensure that bugs are not inadvertently reported there - an advisory notice somewhere on that site should suffice. > https://bugs.jython.org/issue2892 opened to cover this. I'll try, > starting withthe obvious way > ( > https://help.github.com/en/github/importing-your-projects-to-github/importing-a-repository-with-github-importer) > > and reading what CPython did. I'd be happy to take input from anyone > with a sure-fire answer. > > -- > Jeff Allen > |
|
From: Jeff A. <ja...@fa...> - 2020-05-25 15:43:26
|
We've wanted to do this for ages. If you go back far enough, you can find Jim confidently asserting we'd use GitHub for 2.7.2 (https://sourceforge.net/p/jython/mailman/jython-dev/thread/CAOhO%3DaO_4GruQXQqmZk39a0C%3DXUnKyj%3DG6OcQtBkhtoQm9BCjw%40mail.gmail.com/#msg35054683). Building with Gradle and accessing dependencies remotely (no JARs checked in) were identified as prerequisites at the time. In turn, I think building with Gradle requires re-organising the code to fit with its /convention over configuration/ idea (https://docs.gradle.org/current/userguide/organizing_gradle_projects.html#sec:use_standard_conventions). At least, doing otherwise in 2.7.2 got too difficult for me, somewhere around exposed classes ISTR. These don't seem to be prerequisites for the move. I would do Jython 3 that way, but leave 2.7.3 as it is. https://bugs.jython.org/issue2892 opened to cover this. I'll try, starting withthe obvious way (https://help.github.com/en/github/importing-your-projects-to-github/importing-a-repository-with-github-importer) and reading what CPython did. I'd be happy to take input from anyone with a sure-fire answer. -- Jeff Allen |
|
From: Jython t. <st...@bu...> - 2020-05-22 18:05:35
|
ACTIVITY SUMMARY (2020-05-15 - 2020-05-22) Jython tracker at https://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 342 ( +1) closed 2484 ( +0) total 2826 ( +1) Open issues with patches: 22 Issues opened (1) ================= #2890: Jython fails to install and run in Win 10 Pro https://bugs.jython.org/issue2890 opened by sherif Most recent 15 issues with no replies (15) ========================================== #2890: Jython fails to install and run in Win 10 Pro https://bugs.jython.org/issue2890 #2886: doing relative imports in a loop causes bad performance due to https://bugs.jython.org/issue2886 #2882: A cmd.exe in the CWD will be executed unexpectedly https://bugs.jython.org/issue2882 #2878: java.lang.OutOfMemoryError: Java heap space https://bugs.jython.org/issue2878 #2876: NullPointer exception PyModule.java https://bugs.jython.org/issue2876 #2874: Jython 2.7 is not able to import an EBCDIC file on z/OS https://bugs.jython.org/issue2874 #2866: Interface default methods disregarded by the method resolver https://bugs.jython.org/issue2866 #2864: Importing second instance of httplib causes an error https://bugs.jython.org/issue2864 #2854: from module import * leads to wild goose chase https://bugs.jython.org/issue2854 #2798: OpenJDK 1.7.0_75-b13 string regrtest OutOfMemory on windows https://bugs.jython.org/issue2798 #2794: invocation_tests.py missing from modjy tests https://bugs.jython.org/issue2794 #2792: Failures in test_import_jy from Java 13 https://bugs.jython.org/issue2792 #2790: Equivalent signal handlers do not test equal using == https://bugs.jython.org/issue2790 #2770: PBKDF-OpenSSL SecretKeyFactory not available on Java 7 https://bugs.jython.org/issue2770 #2760: How to call procedure with use zxjdbc and get back OUT paramet https://bugs.jython.org/issue2760 Most recent 15 issues waiting for review (15) ============================================= #2566: inspect does not recognize code objects from bytecode files https://bugs.jython.org/issue2566 #2545: help() does not work on Java-implemented modules https://bugs.jython.org/issue2545 #2429: cStringIO does not work with mutable objects implementing the https://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses https://bugs.jython.org/issue2367 #2363: relative seeks works incorrectly after readline https://bugs.jython.org/issue2363 #2143: site-packages support in standalone jar https://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context https://bugs.jython.org/issue2142 #1925: Support loading java.sql.Drivers that aren't on the boot class https://bugs.jython.org/issue1925 #1917: No ctypes.c_char https://bugs.jython.org/issue1917 #1842: Add IBM i support to Jython https://bugs.jython.org/issue1842 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo https://bugs.jython.org/issue1741 #1646: Proxy getInterface not change for more PyObject https://bugs.jython.org/issue1646 #1612: array.array should use specialized bulk operations to initiali https://bugs.jython.org/issue1612 #1435: traceback doesn't include Java stack trace in user functions https://bugs.jython.org/issue1435 #1336: PyDeque should likely subclass PySequence https://bugs.jython.org/issue1336 |
|
From: Rory O'D. <ror...@or...> - 2020-05-22 08:00:55
|
Hi Alan, OpenJDK 15 EA build 24 is now available at http://jdk.java.net/15 * * * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Features o Proposed to target JDK 15 + JEP 383 <https://openjdk.java.net/jeps/383> Foreign-Memory Access API (Second Incubator) o Targeted to JDK 15 + JEP 360 <http://openjdk.java.net/jeps/360> Sealed Classes (Preview) + JEP 379 <https://openjdk.java.net/jeps/379> Shenandoah: A Low-Pause-Time Garbage Collector (Production) o Integrated in JDK 15 + JEP 339 <http://openjdk.java.net/jeps/339> Edwards-Curve Digital Signature Algorithm (EdDSA) + JEP 371 <http://openjdk.java.net/jeps/371> Hidden Classes + JEP 372 <http://openjdk.java.net/jeps/372> Remove the Nashorn JavaScript Engine + *JEP 373 <https://openjdk.java.net/jeps/373>**Reimplement the Legacy DatagramSocket API* + JEP 374 <http://openjdk.java.net/jeps/374> Disable and Deprecate Biased Locking + JEP 375 <https://openjdk.java.net/jeps/375> Pattern Matching for instanceof (Second Preview) + JEP 377 <http://openjdk.java.net/jeps/377> ZGC: A Scalable Low-Latency Garbage Collector + JEP 378 <http://openjdk.java.net/jeps/378> Text Blocks + JEP 381 <https://openjdk.java.net/jeps/381> Remove the Solaris and SPARC Ports + JEP 384 <https://openjdk.java.net/jeps/384> Records (Second Preview) * Changes in recent builds that maybe of interest: o build 24 + *JEP 373 <https://openjdk.java.net/jeps/373>**Reimplement the Legacy DatagramSocket API *(JDK-8241072 <https://bugs.openjdk.java.net/browse/JDK-8241072>) + *JEP 374 <http://openjdk.java.net/jeps/374> *Disable and Deprecate Biased Locking (JDK-8231264 <https://bugs.openjdk.java.net/browse/JDK-8231264>) + Support for Unicode 13.0**(JDK-8239383 <https://bugs.openjdk.java.net/browse/JDK-8239383>) + Incorrect Man pages of Javadocs tool (JDK-8238697 <https://bugs.openjdk.java.net/browse/JDK-8238697>) # reported by Apache Lucene + 32-bit builds are broken after JDK-8242524 (JDK-8245070 <https://bugs.openjdk.java.net/browse/JDK-8245070>) # Reported by JaCoCo* * o build 23 + localizedBy() should override localized values with default values (JDK-8244245 <https://bugs.openjdk.java.net/browse/JDK-8244245>) + Add revocation checking to jarsigner (JDK-8242060) <https://bugs.openjdk.java.net/browse/JDK-8242060> o build 22 + Deprecate -XX:ForceNUMA option (JDK-8243628 <https://bugs.openjdk.java.net/browse/JDK-8243628>) + Removal of Comodo Root CA Certificate (JDK-8225069 <https://bugs.openjdk.java.net/browse/JDK-8225069>) + Removal of DocuSign Root CA Certificate (JDK-8225068 <https://bugs.openjdk.java.net/browse/JDK-8225068>) * Project Lanai Early-Access Builds - Build 15-lanai+1-101 (2020/5/14) o These builds are intended for developers looking to test and provide feedback on using Project Lanai, which implements a new Java 2D graphics rendering pipeline for macOS. o These builds are based upon the latest state of the current in development JDK, and so may contain new features and unresolved bugs unrelated to Project Lanai. o These early-access , open-source builds are provided under the + GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. o Please send feedback via e-mail to lan...@op... <mailto:lan...@op...>. To send e-mail to this address you must first subscribe to the mailing list <https://mail.openjdk.java.net/mailman/listinfo/lanai-dev>. * Project Loom Early-Access Builds - Build 15-loom+7-141 (2020/5/11) o These builds are intended for developers looking to "kick the tyres" and provide feedback on using the API or by sending bug reports. Warning: This build is based on an incomplete version of JDK 15 <http://openjdk.java.net/projects/jdk/15/>. o These early-access , open-source builds are provided under the + GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. o Please send feedback via e-mail to loo...@op... <mailto:loo...@op...>. To send e-mail to this address you must first subscribe to the mailing list <http://mail.openjdk.java.net/mailman/listinfo/loom-dev>. *The **Java Crypto Roadmap** has been updated [2]* Rgds,Rory [1] http://jdk.java.net/15/release-notes [2] https://www.java.com/en/jre-jdk-cryptoroadmap.html -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland |
|
From: Adam B. <ada...@gm...> - 2020-05-22 03:21:07
|
Ok - PR here: https://github.com/jython/jython.github.io/pull/19 Adam On Sun, 3 May 2020 at 03:52, Eero Aaltonen <eer...@ik...> wrote: > Hi Adam, > > The bazel.build includes an SHA1 checksum, which can be used for limited > verification. It is still however hosted on the same server infrastructure. > > Providing the users the means to verify the installer against the PGP > public key of someone doing the release is less vulnerable to malicious > actors (*assuming the* * developers who perform a release keep their > private key.. private).* > > So in a nutshell, the PGP verification is more resilient security wise. > > Cheers, > Eero > > On Sat, May 2, 2020 at 3:14 PM Adam Burke <ada...@gm...> wrote: > >> Thanks Eero. Sorry this flew under the radar earlier. >> >> I guess the intent on the download page is all that information is >> available using the "metadata" link, eg >> >> Jython Installer >> <https://repo1.maven.org/maven2/org/python/jython-installer/2.7.2/jython-installer-2.7.2.jar> - >> Use this to install Jython. (metadata >> <https://search.maven.org/artifact/org.python/jython-installer/2.7.2/jar> >> ) >> >> Do you think that's too obscure, or introduces some security risk? I note >> the CPython download page links to the .asc sig file for their downloads >> too. >> >> Cheers >> Adam >> >> >> On Sun, 5 Apr 2020 at 23:17, Eero Aaltonen <eer...@ik...> wrote: >> >>> Thank you for your hard work on making the release! >>> >>> The obvious place to download the release >>> https://www.jython.org/download.html >>> >>> Currently does not have obvious instructions for verifying the download. >>> Everything required for that however seems to be in place: >>> * https://repo1.maven.org/maven2/org/python/jython-installer/2.7.2/ >>> .asc signatures >>> * >>> https://jython-devguide.readthedocs.io/en/latest/release_jy.html#publication >>> releases (Jeff's) public key on the keyserver. >>> >>> In case you wish to add verification instructions to the download page, >>> I make a sketch while doing that myself >>> >>> >>> ## Download release and signature >>> >>> Download files >>> >>> * `jython-installer-2.7.2.jar` >>> * `jython-installer-2.7.2.jar.asc` from example >>> https://repo1.maven.org/maven2/org/python/jython-installer/2.7.2/ >>> >>> ## Identify Signing Key >>> >>> `gpg --verify jython-installer-2.7.2.jar.asc jython-installer-2.7.2.jar` >>> >>> ## Search and Import Key >>> >>> `gpg --keyserver hkp://pool.sks-keyservers.net --search-keys >>> C8C4B9DC1E031F788B12882B875C3EF9DC4638E3` >>> >>> ## Verify >>> >>> Run the verification command again >>> >>> `gpg --verify jython-installer-2.7.2.jar.asc jython-installer-2.7.2.jar` >>> _______________________________________________ >>> Jython-dev mailing list >>> Jyt...@li... >>> https://lists.sourceforge.net/lists/listinfo/jython-dev >>> >> |
|
From: Jeff A. <ja...@fa...> - 2020-05-16 14:03:35
|
Hi Albert: I was going to ask for an isolated example, which might still be useful, but if you have a solution, that's even more interesting. Either open an issue at bugs.jython.org and attach a patch, or make a PR at https://github.com/jythontools/jython . In the latter case, we will go via a patch because we don't (for now) master the repo at GitHub. Actually, that's probably the next action for the project: move to GitHub. Jeff Allen On 16/05/2020 14:13, Albert Cardona wrote: > Hi all, > I think I can improve the performance of imap significantly. > Would you take pull requests at > https://github.com/jythontools/jython/blob/master/src/org/python/modules/itertools/imap.java ? > Or should one submit patches to the mercurial repository? > Thanks, > Albert > >> On May 16, 2020, at 12:09 AM, Albert Cardona <sap...@gm...> wrote: >> >> Hi all, >> >> I am seeing severe performance problems when looping over sequences >> and invoking a single method on each element of the sequence, both >> with a for loop and with an imap + deque maxlen=0 strategy. The >> baseline is clojure, which is fully typed and compiled to bytecode. >> >> The difference is staggering: 500x to 1000x (from about 1 second to 1 >> millisecond). >> >> Here is a script that can run in Fiji: >> >> https://github.com/acardona/scripts/blob/dev/python/imagej/tests/test_looping_performance_imglib2_setOne.py >> >> The script creates an ImgLib2 image of width=512, height=512, depth=5, >> of type unsigned byte, and then loops over all pixels to invoke the >> method "setOne" on each pixel (pixels are presented as wrapped by an >> UnsignedByteType object that offers the "setOne" method). There is an >> underlying byte[] array of size 512*512*5 to the image. >> >> Why the enormous difference? Anything that can be done to mitigate >> this issue? >> >> Thank you very much. >> >> Albert > > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
|
From: Albert C. <sap...@gm...> - 2020-05-16 13:37:37
|
Thank you Jeff. I will hack a bit and test. My solution will consist in removing if/else code and other friction by making different PyIterator subclasses depending on the number of arguments, for 1,2,3,4 arguments. Above 4, the current approach should do. Tests will show whether my intuition is wrong. Best wishes, Albert Missatge de Jeff Allen <ja...@fa...> del dia ds., 16 de maig 2020 a les 14:24: > > Hi Albert: > > I was going to ask for an isolated example, which might still be useful, but if you have a solution, that's even more interesting. > > Either open an issue at bugs.jython.org and attach a patch, or make a PR at https://github.com/jythontools/jython . In the latter case, we will go via a patch because we don't (for now) master the repo at GitHub. > > Actually, that's probably the next action for the project: move to GitHub. > > Jeff Allen > > On 16/05/2020 14:13, Albert Cardona wrote: > > Hi all, > I think I can improve the performance of imap significantly. > Would you take pull requests at https://github.com/jythontools/jython/blob/master/src/org/python/modules/itertools/imap.java ? > Or should one submit patches to the mercurial repository? > Thanks, > Albert > > On May 16, 2020, at 12:09 AM, Albert Cardona <sap...@gm...> wrote: > > Hi all, > > I am seeing severe performance problems when looping over sequences > and invoking a single method on each element of the sequence, both > with a for loop and with an imap + deque maxlen=0 strategy. The > baseline is clojure, which is fully typed and compiled to bytecode. > > The difference is staggering: 500x to 1000x (from about 1 second to 1 > millisecond). > > Here is a script that can run in Fiji: > > https://github.com/acardona/scripts/blob/dev/python/imagej/tests/test_looping_performance_imglib2_setOne.py > > The script creates an ImgLib2 image of width=512, height=512, depth=5, > of type unsigned byte, and then loops over all pixels to invoke the > method "setOne" on each pixel (pixels are presented as wrapped by an > UnsignedByteType object that offers the "setOne" method). There is an > underlying byte[] array of size 512*512*5 to the image. > > Why the enormous difference? Anything that can be done to mitigate this issue? > > Thank you very much. > > Albert > > > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
|
From: Albert C. <sap...@gm...> - 2020-05-16 13:35:48
|
Thanks Adam! By the way, the link to the repository at https://jython-devguide.readthedocs.io/en/latest/ (point 2, github) is wrong: it's jythontools/jython, not jython/jython Best wishes, Albert Missatge de Jeff Allen <ja...@fa...> del dia ds., 16 de maig 2020 a les 14:24: > > Hi Albert: > > I was going to ask for an isolated example, which might still be useful, but if you have a solution, that's even more interesting. > > Either open an issue at bugs.jython.org and attach a patch, or make a PR at https://github.com/jythontools/jython . In the latter case, we will go via a patch because we don't (for now) master the repo at GitHub. > > Actually, that's probably the next action for the project: move to GitHub. > > Jeff Allen > > On 16/05/2020 14:13, Albert Cardona wrote: > > Hi all, > I think I can improve the performance of imap significantly. > Would you take pull requests at https://github.com/jythontools/jython/blob/master/src/org/python/modules/itertools/imap.java ? > Or should one submit patches to the mercurial repository? > Thanks, > Albert > > On May 16, 2020, at 12:09 AM, Albert Cardona <sap...@gm...> wrote: > > Hi all, > > I am seeing severe performance problems when looping over sequences > and invoking a single method on each element of the sequence, both > with a for loop and with an imap + deque maxlen=0 strategy. The > baseline is clojure, which is fully typed and compiled to bytecode. > > The difference is staggering: 500x to 1000x (from about 1 second to 1 > millisecond). > > Here is a script that can run in Fiji: > > https://github.com/acardona/scripts/blob/dev/python/imagej/tests/test_looping_performance_imglib2_setOne.py > > The script creates an ImgLib2 image of width=512, height=512, depth=5, > of type unsigned byte, and then loops over all pixels to invoke the > method "setOne" on each pixel (pixels are presented as wrapped by an > UnsignedByteType object that offers the "setOne" method). There is an > underlying byte[] array of size 512*512*5 to the image. > > Why the enormous difference? Anything that can be done to mitigate this issue? > > Thank you very much. > > Albert > > > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
|
From: Adam B. <ada...@gm...> - 2020-05-16 13:24:01
|
Hi Albert A PR is standard. The mercurial stuff is involved in applying the final patch but patch submitters don't need to worry about it. Dev guide here https://jython-devguide.readthedocs.io/en/latest/ Cheers Adam On Sat, 16 May 2020 at 23:14, Albert Cardona <sap...@gm...> wrote: > Hi all, > I think I can improve the performance of imap significantly. > Would you take pull requests at > https://github.com/jythontools/jython/blob/master/src/org/python/modules/itertools/imap.java > ? > Or should one submit patches to the mercurial repository? > Thanks, > Albert > > On May 16, 2020, at 12:09 AM, Albert Cardona <sap...@gm...> wrote: > > Hi all, > > I am seeing severe performance problems when looping over sequences > and invoking a single method on each element of the sequence, both > with a for loop and with an imap + deque maxlen=0 strategy. The > baseline is clojure, which is fully typed and compiled to bytecode. > > The difference is staggering: 500x to 1000x (from about 1 second to 1 > millisecond). > > Here is a script that can run in Fiji: > > > https://github.com/acardona/scripts/blob/dev/python/imagej/tests/test_looping_performance_imglib2_setOne.py > > The script creates an ImgLib2 image of width=512, height=512, depth=5, > of type unsigned byte, and then loops over all pixels to invoke the > method "setOne" on each pixel (pixels are presented as wrapped by an > UnsignedByteType object that offers the "setOne" method). There is an > underlying byte[] array of size 512*512*5 to the image. > > Why the enormous difference? Anything that can be done to mitigate this > issue? > > Thank you very much. > > Albert > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Albert C. <sap...@gm...> - 2020-05-16 13:13:52
|
Hi all, I think I can improve the performance of imap significantly. Would you take pull requests at https://github.com/jythontools/jython/blob/master/src/org/python/modules/itertools/imap.java ? Or should one submit patches to the mercurial repository? Thanks, Albert > On May 16, 2020, at 12:09 AM, Albert Cardona <sap...@gm...> wrote: > > Hi all, > > I am seeing severe performance problems when looping over sequences > and invoking a single method on each element of the sequence, both > with a for loop and with an imap + deque maxlen=0 strategy. The > baseline is clojure, which is fully typed and compiled to bytecode. > > The difference is staggering: 500x to 1000x (from about 1 second to 1 > millisecond). > > Here is a script that can run in Fiji: > > https://github.com/acardona/scripts/blob/dev/python/imagej/tests/test_looping_performance_imglib2_setOne.py > > The script creates an ImgLib2 image of width=512, height=512, depth=5, > of type unsigned byte, and then loops over all pixels to invoke the > method "setOne" on each pixel (pixels are presented as wrapped by an > UnsignedByteType object that offers the "setOne" method). There is an > underlying byte[] array of size 512*512*5 to the image. > > Why the enormous difference? Anything that can be done to mitigate this issue? > > Thank you very much. > > Albert |
|
From: Albert C. <sap...@gm...> - 2020-05-15 23:09:48
|
Hi all, I am seeing severe performance problems when looping over sequences and invoking a single method on each element of the sequence, both with a for loop and with an imap + deque maxlen=0 strategy. The baseline is clojure, which is fully typed and compiled to bytecode. The difference is staggering: 500x to 1000x (from about 1 second to 1 millisecond). Here is a script that can run in Fiji: https://github.com/acardona/scripts/blob/dev/python/imagej/tests/test_looping_performance_imglib2_setOne.py The script creates an ImgLib2 image of width=512, height=512, depth=5, of type unsigned byte, and then loops over all pixels to invoke the method "setOne" on each pixel (pixels are presented as wrapped by an UnsignedByteType object that offers the "setOne" method). There is an underlying byte[] array of size 512*512*5 to the image. Why the enormous difference? Anything that can be done to mitigate this issue? Thank you very much. Albert |
101 messages has been excluded from this view by a project administrator.
