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...> - 2016-07-15 16:10:23
|
ACTIVITY SUMMARY (2016-07-08 - 2016-07-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 289 ( +1) closed 2239 ( +0) total 2528 ( +1) Open issues with patches: 28 Issues opened (1) ================= #2509: Demo/modjy_webapp is not working when deployed to Weblogic 12c http://bugs.jython.org/issue2509 opened by ram4444 Most recent 15 issues with no replies (15) ========================================== #2509: Demo/modjy_webapp is not working when deployed to Weblogic 12c http://bugs.jython.org/issue2509 #2507: Run "invokeFunction" in a thread does not inherit the "ScriptC http://bugs.jython.org/issue2507 #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 #2418: test_chdir subprocess tests fail on Windows http://bugs.jython.org/issue2418 #2410: Regression in PySystemStateTest (leading slash) http://bugs.jython.org/issue2410 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #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 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #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 #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 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 |
|
From: Jeff A. <ja...@fa...> - 2016-07-15 07:42:52
|
Stefan: I recently pushed more changes to my bitbucket fork, including addition of a getObj() to PyBuffer in response to your need to navigate to the exporting object. The existing PyBuffer interface provides copyTo/From byte arrays. With support for non-heap NIO storage it seems natural (and not too hard) to add copyTo/From ByteBuffer. At present these are in the NIO implementation, but not made interface items. Do you think this would be bloat, nice-to-have, or really useful for what you were hoping to do? Jeff Jeff Allen On 13/06/2016 01:04, Stefan Richthofer wrote: > Hey Jeff, > thanks a lot for this work. I will take a closer look as soon as I find time. > However, so far - quickly scrolling through some source-files - it looks pretty good. > > Best > > Stefan > > > >> Gesendet: Samstag, 11. Juni 2016 um 11:37 Uhr >> Von: "Jeff Allen" <ja...@fa...> >> An: "Stefan Richthofer" <Ste...@gm...> >> Cc: "Jython Developers" <jyt...@li...> >> Betreff: Re: [Jython-dev] Jython buffer protocol >> >> Stefan: >> >> A sane version of the nio buffer work now exists for your delight at: >> https://bitbucket.org/tournesol/jython-nio >> <snip> |
|
From: Isaiah P. <is...@gm...> - 2016-07-11 14:58:08
|
Hi Jeff, Thanks for the hint, indeed the initialize error is gone once I added the `build/exposed` (the default path in which exposed .class files are dumped) path to intellij as `resource`, now I got a different error but I think it's somehow related to configuration of environment you mentioned above. I am working on exposing the builtin modules in a similar way as the builtin types, so that they can be proper modules in Python. Currently they are 'type` and the module functions are reflected. Cheers, Isaiah On Mon, 11 Jul 2016 at 11:08 Jeff Allen <ja...@fa...> wrote: > Hi Isaiah, > > I'm using Eclipse (and mostly on Windows), so this is likely to be > different for you, however ... > > Jython-the-program has always run very badly for me under the IDE: I > just don't seem to be able to give it the environment it needs, and > console I/O is a basket case. I always run Jython at the command prompt. > If I need to single-step the code, I use remote debugging. > > JUnit tests, on the other hand, work brilliantly under the IDE, > including debugging. The only niggle I commonly encounter is that to > raise a PyException I have to create an instance of the interpreter > (static PythonInterpreter interp = new PythonInterpreter(); ) in my test > fixture. > > Finding the built-in types uninitialised is, for me, a symptom of having > the build path in the wrong order. In some circumstances (debugging > exposed classes, and between "clean" and "build", I think) one has to > have the ~/src directory first, but this then means that when loading > classes, the JVM finds the unexposed version of the class instead of the > exposed one -- not that ~/src contains any classes, but I think Eclipse > helpfully finds them. So mostly I have the ~/exposed directory first, > and ensure "expose" has run on the latest source. > > Now if you're actually testing the exposer ... that seems likely to add > a whole new layer of confusion, but I hope some of the above helps. > > Jeff > > Jeff Allen > > On 08/07/2016 10:15, Isaiah Peng wrote: > > Hi Guys, > > > > When run the java tests with intellij, it fails initialize the > > PySystemState in the setup phrase, digged a bit, I think that the > > exposed types are not correctly instrumented. The same test runs with > > the ant task: > > > > ant singlejavatest -DExposedTypeProcessorTest > > > > I've added the `ant expose` task to intellij run configuration, but it > > doesn't make any difference. > > > > Not sure if it is even possible to run the tests in IDE, do you have > > any suggestions? > > > > Best, > > Isaiah > > > > > > ------------------------------------------------------------------------------ > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San > Francisco, CA to explore cutting-edge tech and listen to tech luminaries > present their vision of the future. This family event has something for > everyone, including kids. Get more information and register today. > http://sdm.link/attshape > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Jeff A. <ja...@fa...> - 2016-07-11 09:07:13
|
Hi Isaiah, I'm using Eclipse (and mostly on Windows), so this is likely to be different for you, however ... Jython-the-program has always run very badly for me under the IDE: I just don't seem to be able to give it the environment it needs, and console I/O is a basket case. I always run Jython at the command prompt. If I need to single-step the code, I use remote debugging. JUnit tests, on the other hand, work brilliantly under the IDE, including debugging. The only niggle I commonly encounter is that to raise a PyException I have to create an instance of the interpreter (static PythonInterpreter interp = new PythonInterpreter(); ) in my test fixture. Finding the built-in types uninitialised is, for me, a symptom of having the build path in the wrong order. In some circumstances (debugging exposed classes, and between "clean" and "build", I think) one has to have the ~/src directory first, but this then means that when loading classes, the JVM finds the unexposed version of the class instead of the exposed one -- not that ~/src contains any classes, but I think Eclipse helpfully finds them. So mostly I have the ~/exposed directory first, and ensure "expose" has run on the latest source. Now if you're actually testing the exposer ... that seems likely to add a whole new layer of confusion, but I hope some of the above helps. Jeff Jeff Allen On 08/07/2016 10:15, Isaiah Peng wrote: > Hi Guys, > > When run the java tests with intellij, it fails initialize the > PySystemState in the setup phrase, digged a bit, I think that the > exposed types are not correctly instrumented. The same test runs with > the ant task: > > ant singlejavatest -DExposedTypeProcessorTest > > I've added the `ant expose` task to intellij run configuration, but it > doesn't make any difference. > > Not sure if it is even possible to run the tests in IDE, do you have > any suggestions? > > Best, > Isaiah > |
|
From: Jython t. <st...@bu...> - 2016-07-08 16:10:22
|
ACTIVITY SUMMARY (2016-07-01 - 2016-07-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 288 ( +2) closed 2239 ( +0) total 2527 ( +2) Open issues with patches: 28 Issues opened (2) ================= #2507: Run "invokeFunction" in a thread does not inherit the "ScriptC http://bugs.jython.org/issue2507 opened by jjdelcerro #2508: Jython non-blocking socket send() does not conform to Python's http://bugs.jython.org/issue2508 opened by ryan.springer Most recent 15 issues with no replies (15) ========================================== #2507: Run "invokeFunction" in a thread does not inherit the "ScriptC http://bugs.jython.org/issue2507 #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 #2418: test_chdir subprocess tests fail on Windows http://bugs.jython.org/issue2418 #2410: Regression in PySystemStateTest (leading slash) http://bugs.jython.org/issue2410 #2408: Redo sre port for regular expression support http://bugs.jython.org/issue2408 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #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 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #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 #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 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 |
|
From: Isaiah P. <is...@gm...> - 2016-07-08 09:15:29
|
Hi Guys, When run the java tests with intellij, it fails initialize the PySystemState in the setup phrase, digged a bit, I think that the exposed types are not correctly instrumented. The same test runs with the ant task: ant singlejavatest -DExposedTypeProcessorTest I've added the `ant expose` task to intellij run configuration, but it doesn't make any difference. Not sure if it is even possible to run the tests in IDE, do you have any suggestions? Best, Isaiah |
|
From: Jython t. <st...@bu...> - 2016-07-01 16:10:21
|
ACTIVITY SUMMARY (2016-06-24 - 2016-07-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 286 ( +1) closed 2239 ( +0) total 2525 ( +1) Open issues with patches: 28 Issues opened (1) ================= #2506: ensurepip is reporting an error http://bugs.jython.org/issue2506 opened by docian Most recent 15 issues with no replies (15) ========================================== #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 #2418: test_chdir subprocess tests fail on Windows http://bugs.jython.org/issue2418 #2410: Regression in PySystemStateTest (leading slash) http://bugs.jython.org/issue2410 #2408: Redo sre port for regular expression support http://bugs.jython.org/issue2408 #2369: running jython-standalone.jar in desktops with with korean lan http://bugs.jython.org/issue2369 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #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 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #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 #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 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 |
|
From: Rory O'D. <ror...@or...> - 2016-06-27 09:02:08
|
Hi Alan, Early Access b124 <https://jdk9.java.net/download/> for JDK 9 is available on java.net, summary of changes are listed here <http://www.java.net/download/java/jdk9/changes/jdk-9+120.html>. Early Access b123 <https://jdk9.java.net/jigsaw/> (#5178) for JDK 9 with Project Jigsaw is available on java.net, summary of changes are listed here <http://download.java.net/java/jigsaw/archive/123/binaries/jdk-9+123.html> Early Access b01 <https://jdk8.java.net/download.html> for JDK 8u112 is available on java.net. Update to JEP 261 : Module System - email from Mark Reinhold [1] - The special ALL-DEFAULT module name, which represents the default set of root modules for use with the -addmods option [2]; - A more thorough explanation of how the built-in class loaders have changed, how built-in modules are assigned to each loader, and how these loaders work together to load classes [3]; and - The reason why Java EE-related modules are no longer resolved by default [4]. - There are various other minor corrections and clarifications, as can be seen in the detailed diff [5]. Rgds,Rory [1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-June/008227.html [2]http://openjdk.java.net/jeps/261#ALL-DEFAULT [3]http://openjdk.java.net/jeps/261#Class-loaders [4]http://openjdk.java.net/jeps/261#EE-modules [5]http://cr.openjdk.java.net/~mr/jigsaw/jeps/updates/261-2016-06-15.html <http://cr.openjdk.java.net/%7Emr/jigsaw/jeps/updates/261-2016-06-15.html> -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland |
|
From: Jython t. <st...@bu...> - 2016-06-24 16:10:21
|
ACTIVITY SUMMARY (2016-06-17 - 2016-06-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 285 ( +0) closed 2239 ( +0) total 2524 ( +0) Open issues with patches: 28 Most recent 15 issues with no replies (15) ========================================== #2504: JTable displays incorrect dates with Jython 2.7.0 http://bugs.jython.org/issue2504 #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 #2418: test_chdir subprocess tests fail on Windows http://bugs.jython.org/issue2418 #2410: Regression in PySystemStateTest (leading slash) http://bugs.jython.org/issue2410 #2408: Redo sre port for regular expression support http://bugs.jython.org/issue2408 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #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 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #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 #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 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 |
|
From: Jython t. <st...@bu...> - 2016-06-17 16:10:21
|
ACTIVITY SUMMARY (2016-06-10 - 2016-06-17) 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 285 ( +2) closed 2239 ( +0) total 2524 ( +2) Open issues with patches: 28 Issues opened (2) ================= #2504: JTable displays incorrect dates with Jython 2.7.0 http://bugs.jython.org/issue2504 opened by ttakamiy #2505: PySystemState is lost http://bugs.jython.org/issue2505 opened by jsaiz Most recent 15 issues with no replies (15) ========================================== #2504: JTable displays incorrect dates with Jython 2.7.0 http://bugs.jython.org/issue2504 #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 #2418: test_chdir subprocess tests fail on Windows http://bugs.jython.org/issue2418 #2410: Regression in PySystemStateTest (leading slash) http://bugs.jython.org/issue2410 #2408: Redo sre port for regular expression support http://bugs.jython.org/issue2408 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #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 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #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 #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 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 |
|
From: Stefan R. <Ste...@gm...> - 2016-06-13 00:04:28
|
Hey Jeff, thanks a lot for this work. I will take a closer look as soon as I find time. However, so far - quickly scrolling through some source-files - it looks pretty good. Best Stefan > Gesendet: Samstag, 11. Juni 2016 um 11:37 Uhr > Von: "Jeff Allen" <ja...@fa...> > An: "Stefan Richthofer" <Ste...@gm...> > Cc: "Jython Developers" <jyt...@li...> > Betreff: Re: [Jython-dev] Jython buffer protocol > > Stefan: > > A sane version of the nio buffer work now exists for your delight at: > https://bitbucket.org/tournesol/jython-nio > > I've chosen configuration options at Bitbucket to avoid anyone forking > it and to try to avoid unnecessary merges finding their way into the > main Jython repo. However, I wouldn't have committed it even locally if > it weren't pretty good. If these tricks prevent you getting the code, > let me know and I'll open it up a bit more. > > test_memoryview fails because my new code does not correctly handle > overlapped copy to self. A fix will follow. The strided overlapped case > is quite tricky, and I think it must have been broken all along. (I > wonder if CPython gets it right.) > > Jeff > > Jeff Allen > > On 04/06/2016 17:50, Jeff Allen wrote: > > After extensive refactoring, I'm close now to a satisfactory solution > > based on parallel hierarchies: one for byte[] and one for ByteBuffer, > > each with its own JUnit test. Tests pass on both, including when I > > allocate direct buffers. > > > > I had a shot at simply replacing the prior implementation of the buffers > > with one based on ByteBuffer, wrapping an array where that's the real > > storage. It nearly worked, but involved breaking too many things at once > > to keep track of, and it was just easier to build a new one next door. > > > > I think having two implementations has helped me get the base material > > (BaseBuffer and the test support) into better shape. It was less clear > > what should be in the base material, and what belongs to a particular > > implementation choice, when there was only one. This is the bit I'm > > polishing now. I'm also enjoying how JUnit4 parameterisation lets me > > debug just one implementation type at a time. > > > > I should have something to show this week. > > > > Jeff Allen > > > > On 11/05/2016 19:14, Jeff Allen wrote: > >> On 11/05/2016 14:38, Stefan Richthofer wrote: > >>> Sounds like good news! Would you put a draft e.g. on github once it is > >>> somehow at a sane state? > >> How was it Jim dignified our process ... ah yes, commit-then-review. :) > >> I'll share the elements somehow to check my thinking. > >>>> ByteBuffer getByteBuffer(int... indices); > >>> I wonder what this is supposed to do; afaik ByteBuffer supports no > >>> multi-index logic. (Correct me if I'm wrong). > >> No, but PyBuffer does. The above returns a ByteBuffer where the position > >> has been set corresponding to the index polynomial. > >>>> // Extract column c > >>>> ByteBuffer bb = pybuf.getNIOByteBuffer(PyBUF.FULL); > >>>> for (int r=0; r<x.length; r++) > >>>> x[r] = bb.getFloat( pybuf.index(r,c) ); > >>> This looks slow, because method calls are slow (compared to array-access) > >>> and it requires at least two calls per index. > >> I prefer it to x[r] = pybuf.getByteBuffer(r, c).getFloat() which has > >> object construction too. If you want speed you have to do the index > >> calculation by striding from pybuf.index(0,c), but then you will still > >> call ByteBuffer.getFloat(int) rather than an array access. I think > >> efficiency has ceased to be the main objective. Client code that uses > >> array access (equivalently, Pointer) will break when it encounters your > >> ByteBuffer-based objects, so we should make access via the ByteBuffer > >> convenient. > >>>> I'm following the deprecation route at the moment, but bearing in mind > >>>> Jim's view that breaking change is acceptable by virtue of low adoption, > >>> I wonder if there is any evidence how low adoption currently is at all. > >>> Are there any publicly known projects using this? > >> I abbreviated Jim's argument here. Few and sophisticated enough to adapt > >> was his view. I can't find any public projects using our PyBuffer. To > >> suffer from the change, they would have to be projects that use Pointer, > >> not just PyBuffer. > >> > >> Jeff > >> > > > > ------------------------------------------------------------------------------ > > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > > patterns at an interface-level. Reveals which users, apps, and protocols are > > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > > J-Flow, sFlow and other flows. Make informed decisions using capacity > > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > > _______________________________________________ > > Jython-dev mailing list > > Jyt...@li... > > https://lists.sourceforge.net/lists/listinfo/jython-dev > > > > |
|
From: Jeff A. <ja...@fa...> - 2016-06-11 09:37:35
|
Stefan: A sane version of the nio buffer work now exists for your delight at: https://bitbucket.org/tournesol/jython-nio I've chosen configuration options at Bitbucket to avoid anyone forking it and to try to avoid unnecessary merges finding their way into the main Jython repo. However, I wouldn't have committed it even locally if it weren't pretty good. If these tricks prevent you getting the code, let me know and I'll open it up a bit more. test_memoryview fails because my new code does not correctly handle overlapped copy to self. A fix will follow. The strided overlapped case is quite tricky, and I think it must have been broken all along. (I wonder if CPython gets it right.) Jeff Jeff Allen On 04/06/2016 17:50, Jeff Allen wrote: > After extensive refactoring, I'm close now to a satisfactory solution > based on parallel hierarchies: one for byte[] and one for ByteBuffer, > each with its own JUnit test. Tests pass on both, including when I > allocate direct buffers. > > I had a shot at simply replacing the prior implementation of the buffers > with one based on ByteBuffer, wrapping an array where that's the real > storage. It nearly worked, but involved breaking too many things at once > to keep track of, and it was just easier to build a new one next door. > > I think having two implementations has helped me get the base material > (BaseBuffer and the test support) into better shape. It was less clear > what should be in the base material, and what belongs to a particular > implementation choice, when there was only one. This is the bit I'm > polishing now. I'm also enjoying how JUnit4 parameterisation lets me > debug just one implementation type at a time. > > I should have something to show this week. > > Jeff Allen > > On 11/05/2016 19:14, Jeff Allen wrote: >> On 11/05/2016 14:38, Stefan Richthofer wrote: >>> Sounds like good news! Would you put a draft e.g. on github once it is >>> somehow at a sane state? >> How was it Jim dignified our process ... ah yes, commit-then-review. :) >> I'll share the elements somehow to check my thinking. >>>> ByteBuffer getByteBuffer(int... indices); >>> I wonder what this is supposed to do; afaik ByteBuffer supports no >>> multi-index logic. (Correct me if I'm wrong). >> No, but PyBuffer does. The above returns a ByteBuffer where the position >> has been set corresponding to the index polynomial. >>>> // Extract column c >>>> ByteBuffer bb = pybuf.getNIOByteBuffer(PyBUF.FULL); >>>> for (int r=0; r<x.length; r++) >>>> x[r] = bb.getFloat( pybuf.index(r,c) ); >>> This looks slow, because method calls are slow (compared to array-access) >>> and it requires at least two calls per index. >> I prefer it to x[r] = pybuf.getByteBuffer(r, c).getFloat() which has >> object construction too. If you want speed you have to do the index >> calculation by striding from pybuf.index(0,c), but then you will still >> call ByteBuffer.getFloat(int) rather than an array access. I think >> efficiency has ceased to be the main objective. Client code that uses >> array access (equivalently, Pointer) will break when it encounters your >> ByteBuffer-based objects, so we should make access via the ByteBuffer >> convenient. >>>> I'm following the deprecation route at the moment, but bearing in mind >>>> Jim's view that breaking change is acceptable by virtue of low adoption, >>> I wonder if there is any evidence how low adoption currently is at all. >>> Are there any publicly known projects using this? >> I abbreviated Jim's argument here. Few and sophisticated enough to adapt >> was his view. I can't find any public projects using our PyBuffer. To >> suffer from the change, they would have to be projects that use Pointer, >> not just PyBuffer. >> >> Jeff >> > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Jython t. <st...@bu...> - 2016-06-10 16:10:25
|
ACTIVITY SUMMARY (2016-06-03 - 2016-06-10) 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 283 ( +0) closed 2239 ( +0) total 2522 ( +0) Open issues with patches: 28 Most recent 15 issues with no replies (15) ========================================== #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 #2418: test_chdir subprocess tests fail on Windows http://bugs.jython.org/issue2418 #2410: Regression in PySystemStateTest (leading slash) http://bugs.jython.org/issue2410 #2408: Redo sre port for regular expression support http://bugs.jython.org/issue2408 #2369: running jython-standalone.jar in desktops with with korean lan http://bugs.jython.org/issue2369 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #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 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #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 #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 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 |
|
From: Jeff A. <ja...@fa...> - 2016-06-04 16:50:49
|
After extensive refactoring, I'm close now to a satisfactory solution based on parallel hierarchies: one for byte[] and one for ByteBuffer, each with its own JUnit test. Tests pass on both, including when I allocate direct buffers. I had a shot at simply replacing the prior implementation of the buffers with one based on ByteBuffer, wrapping an array where that's the real storage. It nearly worked, but involved breaking too many things at once to keep track of, and it was just easier to build a new one next door. I think having two implementations has helped me get the base material (BaseBuffer and the test support) into better shape. It was less clear what should be in the base material, and what belongs to a particular implementation choice, when there was only one. This is the bit I'm polishing now. I'm also enjoying how JUnit4 parameterisation lets me debug just one implementation type at a time. I should have something to show this week. Jeff Allen On 11/05/2016 19:14, Jeff Allen wrote: > On 11/05/2016 14:38, Stefan Richthofer wrote: >> Sounds like good news! Would you put a draft e.g. on github once it is >> somehow at a sane state? > How was it Jim dignified our process ... ah yes, commit-then-review. :) > I'll share the elements somehow to check my thinking. >>> ByteBuffer getByteBuffer(int... indices); >> I wonder what this is supposed to do; afaik ByteBuffer supports no >> multi-index logic. (Correct me if I'm wrong). > No, but PyBuffer does. The above returns a ByteBuffer where the position > has been set corresponding to the index polynomial. >>> // Extract column c >>> ByteBuffer bb = pybuf.getNIOByteBuffer(PyBUF.FULL); >>> for (int r=0; r<x.length; r++) >>> x[r] = bb.getFloat( pybuf.index(r,c) ); >> This looks slow, because method calls are slow (compared to array-access) >> and it requires at least two calls per index. > I prefer it to x[r] = pybuf.getByteBuffer(r, c).getFloat() which has > object construction too. If you want speed you have to do the index > calculation by striding from pybuf.index(0,c), but then you will still > call ByteBuffer.getFloat(int) rather than an array access. I think > efficiency has ceased to be the main objective. Client code that uses > array access (equivalently, Pointer) will break when it encounters your > ByteBuffer-based objects, so we should make access via the ByteBuffer > convenient. >>> I'm following the deprecation route at the moment, but bearing in mind >>> Jim's view that breaking change is acceptable by virtue of low adoption, >> I wonder if there is any evidence how low adoption currently is at all. >> Are there any publicly known projects using this? > I abbreviated Jim's argument here. Few and sophisticated enough to adapt > was his view. I can't find any public projects using our PyBuffer. To > suffer from the change, they would have to be projects that use Pointer, > not just PyBuffer. > > Jeff > |
|
From: Jython t. <st...@bu...> - 2016-06-03 16:10:25
|
ACTIVITY SUMMARY (2016-05-27 - 2016-06-03) 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 283 ( +2) closed 2239 ( +0) total 2522 ( +2) Open issues with patches: 28 Issues opened (2) ================= #2502: Missing OpenFlags enum entry makes Jython clash with JRuby dep http://bugs.jython.org/issue2502 opened by kibertoad #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 opened by laurio Most recent 15 issues with no replies (15) ========================================== #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 #2418: test_chdir subprocess tests fail on Windows http://bugs.jython.org/issue2418 #2410: Regression in PySystemStateTest (leading slash) http://bugs.jython.org/issue2410 #2408: Redo sre port for regular expression support http://bugs.jython.org/issue2408 #2369: running jython-standalone.jar in desktops with with korean lan http://bugs.jython.org/issue2369 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #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 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #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 #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 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 |
|
From: Rory O'D. <ror...@or...> - 2016-05-30 12:39:18
|
Hi Alan, Early Access b120 <https://jdk9.java.net/download/> for JDK 9 is available on java.net, summary of changes are listed here <http://www.java.net/download/java/jdk9/changes/jdk-9+120.html>. Early Access b120 <https://jdk9.java.net/jigsaw/> (#5074) for JDK 9 with Project Jigsaw is available on java.net. JDK 9 Build 120 has over *400 *bug fixes, hotspot fixes making a significant contribution. In addition , this build implements JEP 289: Deprecate the Applet API [1] Notable changes since the is last announcement email - in JDK 9 b119 the big change was moving the class file version from 52.0 to 53.0, see [2] for more details. Rgds,Rory [1] JEP 289: Deprecate the Applet API <http://openjdk.java.net/jeps/289> [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-January/003507.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland |
|
From: Javen O'N. <jav...@gm...> - 2016-05-30 07:24:46
|
Will anyone from this list be at US PyCon this week in Portland? Is anyone interested in a meetup (open spaces) or a sprint? I didn't see any Jython-specific talks on the list. |
|
From: Jython t. <st...@bu...> - 2016-05-27 16:10:21
|
ACTIVITY SUMMARY (2016-05-20 - 2016-05-27) 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 281 ( +1) closed 2239 ( +0) total 2520 ( +1) Open issues with patches: 28 Issues opened (1) ================= #2501: JAVA_STACK doesn't work http://bugs.jython.org/issue2501 opened by gsnedders Most recent 15 issues with no replies (15) ========================================== #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 #2418: test_chdir subprocess tests fail on Windows http://bugs.jython.org/issue2418 #2410: Regression in PySystemStateTest (leading slash) http://bugs.jython.org/issue2410 #2408: Redo sre port for regular expression support http://bugs.jython.org/issue2408 #2369: running jython-standalone.jar in desktops with with korean lan http://bugs.jython.org/issue2369 #2341: Invalid Unicode string literals cause console to keep outputti http://bugs.jython.org/issue2341 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #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 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #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 #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 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 |
|
From: Stefan R. <Ste...@gm...> - 2016-05-25 13:50:48
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div> <div>> The object can hand out a second reference to the same PyBuffer. (It's not required to, but the built-ins do.)</div> <div> </div> <div>Good point. Now that you mention it I think it should be possible to identify the actual backend even if distinct PyBuffer objects sharing the same backend (array or ByteBuffer) were exposed. Under this view I agree that the single-threaded case is well solvable (and should be solved) this way i.e. with potential copy-back.</div> <div> </div> <div><br/> Thinking of multi-threaded PyBuffer use:</div> <div> </div> <div>I wondered how CPython deals with this (e.g. when using the threading-module) and tried to find some (official) statement from CPython-world about sharing a buffer between multiple threads, but no luck so far. If anyone has resources or an example about such a use-case, I'd appreciate a pointer.</div> <div> </div> <div>So I suppose the user is fully responsible to synchronize his buffer transactions.</div> <div> </div> <div>Given that a multithreaded BufferProtocol usecase is much more natural in Jython I'd propose we should define a recommended standard process and maybe even API for typical tasks in this setting, e.g. locking a buffer(-section) for write access, or for an atomic-like read/process/write-back transaction.<br/> Having such a standard would yield lock-compatibility between distinct frameworks sharing a buffer-exposing object.<br/> Also, behavior in multithreaded case would become much better predictable/controllable from JyNI perspective. Last but not least it would help to avoid errors (deadlocks etc) in this difficult area; consider that Python users are usually not much experienced with multithread stuff.</div> </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> Dienstag, 17. Mai 2016 um 21:08 Uhr<br/> <b>Von:</b> "Jeff Allen" <ja...@fa...><br/> <b>An:</b> "Stefan Richthofer" <Ste...@gm...><br/> <b>Cc:</b> "Jython Developers" <jyt...@li...><br/> <b>Betreff:</b> Re: [Jython-dev] Buffer protocol - direct vs. JVM ByteBuffers</div> <div name="quoted-content"> <div style="background-color: rgb(255,255,255);">On 17/05/2016 01:52, Stefan Richthofer wrote: <blockquote> <div style="font-family: Verdana;font-size: 12.0px;"> <div> <div>The thread could create two (or more) PyBuffer-views of the same object and hand both to various functions that read and write on them without calling release (and thus trigger copy-back) inbetween. The extension would expect if view 'A' was modified, view 'B' already reflects this modification when passed to another function.</div> </div> </div> </blockquote> The object can hand out a second reference to the same PyBuffer. (It's not required to, but the built-ins do.)<br/> <blockquote> <div style="font-family: Verdana;font-size: 12.0px;"> <div> <div>> The only way I can imagine an object with Java fields as storage giving you a direct ByteBuffer on demand is to allocate one and copy its state there. [...] effectively a change of implementation on the fly.</div> <div> </div> <div>This is what I have in mind. Changing the backend on the fly shouldn't be much more expensive than creating a copy, but would then save the cost of copy-back and entire copy cost for future calls. Using the bulk-set method of ByteBuffer this should be easy and efficient to do (bulk-get to convert the other direction). The only infeasible situation would be if an AS_DIRECT_NIO buffer was requested while an array-backed buffer is exported and not yet released or vise versa.</div> </div> </div> </blockquote> Aye, there's the rub, if at least one is writable.<br/> <blockquote> <div style="font-family: Verdana;font-size: 12.0px;"> <div> <div>In this case the request should just fail. I suppose for sake of debugging we should add a verbose mode/flag that makes Jython print out (or append it to the error message in bufferErrorFromSyndrome) the exact reason why some buffer-request failed so a user is able to identify the design flaw.</div> </div> </div> </blockquote> Exceptions should always be that clear. However, it's not really a design flaw: hold a memoryview, and call a numpy function on the array: it's hardly faulty logic. <blockquote> <div style="font-family: Verdana;font-size: 12.0px;"> <div> <div>> This seems to bring us full circle to the behaviour of Get<PrimitiveType>ArrayElements, except that I suppose the object knows it has done it and can handle intervening access via the Java API</div> <div> </div> <div>Since actual views to the same memory would be shared with (native) extensions unlike Get<PrimitiveType>ArrayElements (in copy-case/no array pinning) this would not break the case described above, where multiple PyBuffer views to the same object are in the game.</div> <div> </div> <div>I'm not sure what you mean by "full circle to the behaviour of Get<PrimitiveType>ArrayElements",</div> </div> </div> </blockquote> I meant in the sense that we have made a copy especially for C and may have to copy it back. You're correct that there are still a number of delicate problems to solve during the period the implementation has changed.<br/> <br/> Jeff <blockquote> <div style="font-family: Verdana;font-size: 12.0px;"> <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> Montag, 16. Mai 2016 um 22:04 Uhr<br/> <b>Von:</b> "Jeff Allen" <a class="moz-txt-link-rfc2396E" href="ja...@fa..." target="_parent"><ja...@fa...></a><br/> <b>An:</b> "Stefan Richthofer" <a class="moz-txt-link-rfc2396E" href="Ste...@gm..." target="_parent"><Ste...@gm...></a><br/> <b>Cc:</b> "Jython Developers" <a class="moz-txt-link-rfc2396E" href="jyt...@li..." target="_parent"><jyt...@li...></a><br/> <b>Betreff:</b> Re: [Jython-dev] Buffer protocol - direct vs. JVM ByteBuffers</div> <div> <div style="background-color: rgb(255,255,255);"> <p>Thanks for that. So, the (possible) copy-back semantics of <tt><span class="cEmphasis">Get<PrimitiveType>ArrayElements</span></tt> effectively make a direct buffer copy of the contents. If the C-code runs in the thread of the Java execution that calls it (or equivalently it is suspended) then to first order the copy causes no problem. But it is not difficult to cook up a scenario where another thread or call-back into Java sees a different state from C.</p> <p>Alternatively, one uses the "critical" methods, and suffers restrictions that are, I expect, unenforcible on arbitrary CPython extension modules, such as being short and not yielding the CPU.</p> <p>I'm reminded of the relationship in CPython between C-code and interpreted code, where the GIL must be held, proving all other threads are "restubg" between instructions, and a context switch is only allowed when surrounded by the appropriate magical incantations. I think the Universe is trying to tell us something.</p> <p>The problem I see with the <tt>DIRECT_NIO</tt> flag is that one cannot expect to choose, at the point of getting a PyBuffer, whether that buffer should be direct or heap. The data that hold the state of an object have a certain implementation in Java, and so the buffer will be a heap buffer. Or one can imagine a <tt>PyObject</tt> whose state is always in a direct <tt>ByteBuffer</tt> (representing an image mapped from disk, say) and then the <tt>PyBuffer</tt> would always be direct. Just possibly objects whose main purpose is to be native-friendly would have that implementation. Just possibly, this is a thing you get to choose when the object is constructed.</p> <p>The only way I can imagine an object with Java fields as storage giving you a direct <tt>ByteBuffer</tt> on demand is to allocate one and copy its state there. This seems to bring us full circle to the behaviour of <tt><span class="cEmphasis">Get<PrimitiveType>ArrayElements</span></tt> , except that I suppose the object knows it has done it and can handle intervening access via the Java API ... effectively a change of implementation on the fly.</p> <pre class="moz-signature">Jeff Allen</pre> <div class="moz-cite-prefix">On 15/05/2016 16:39, Stefan Richthofer wrote:</div> <blockquote> <div style="font-family: Verdana;font-size: 12.0px;"> <div> <div>Just an add-on to my recent post:</div> <div> </div> <div>>It may depend on <tt>storage.hasArray()</tt>, but <tt>storage.isDirect()</tt> seems to make no difference.</div> <div> </div> <div>I think it is likely the JVM does not offer a backing array, if the buffer is created as direct (i.e. these flags likely exclude each other), because this would imply array pinning and all the restrictions coming with it. I didn't test it though, but anyway we cannot rely on the one or other behavior, as doc explicitly does not guarantee a backing array for direct buffers, saying this is "implementation specific".</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> Sonntag, 15. Mai 2016 um 11:57 Uhr<br/> <b>Von:</b> "Jeff Allen" <a class="moz-txt-link-rfc2396E" href="ja...@fa..." target="_parent"><ja...@fa...></a><br/> <b>An:</b> "Stefan Richthofer" <a class="moz-txt-link-rfc2396E" href="Ste...@gm..." target="_parent"><Ste...@gm...></a>, "Jython Developers" <a class="moz-txt-link-rfc2396E" href="jyt...@li..." target="_parent"><jyt...@li...></a><br/> <b>Betreff:</b> [Jython-dev] Buffer protocol - direct vs. JVM ByteBuffers</div> <div> <div style="background-color: rgb(255,255,255);"> <p>Stefan:</p> <p><a class="moz-txt-link-freetext" href="https://github.com/jythontools/jython/pull/39" target="_blank">https://github.com/jythontools/jython/pull/39</a></p> <p>What difference does it make in your use case whether a NIO ByteBuffer is direct or non-direct? I can see why a client might want to know which it had been given, but not why it might want an exception raised in one or other case.</p> <p>Nothing I'm doing seems to depend on what kind of memory the exporting object has, therefore on the implementation type of <tt>ByteBuffer storage</tt>. It may depend on <tt>storage.hasArray()</tt>, but <tt>storage.isDirect()</tt> seems to make no difference.</p> Jeff <pre class="moz-signature">-- Jeff Allen</pre> </div> </div> </div> </div> </div> </div> </blockquote> </div> </div> </div> </div> </div> </div> </blockquote> </div> </div> </div> </div> </div></div></body></html> |
|
From: Jython t. <st...@bu...> - 2016-05-20 16:10:20
|
ACTIVITY SUMMARY (2016-05-13 - 2016-05-20) 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 280 ( +0) closed 2239 ( +0) total 2519 ( +0) Open issues with patches: 28 Most recent 15 issues with no replies (15) ========================================== #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 #2418: test_chdir subprocess tests fail on Windows http://bugs.jython.org/issue2418 #2410: Regression in PySystemStateTest (leading slash) http://bugs.jython.org/issue2410 #2408: Redo sre port for regular expression support http://bugs.jython.org/issue2408 #2369: running jython-standalone.jar in desktops with with korean lan http://bugs.jython.org/issue2369 #2341: Invalid Unicode string literals cause console to keep outputti http://bugs.jython.org/issue2341 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #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 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #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 #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 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 |
|
From: Rory O'D. <ror...@or...> - 2016-05-18 08:28:32
|
Hi Alan, Early Access b118 <https://jdk9.java.net/download/> for JDK 9 is available on java.net, summary of changes are listed here <http://www.java.net/download/java/jdk9/changes/jdk-9+118.html>. Early Access b118 <https://jdk9.java.net/jigsaw/> (#4913) for JDK 9 with Project Jigsaw is available on java.net. JDK 9 Build 118 includes a refresh of the module system. There are several changes in this update, JDK 9 b118 has the updated policy for root modules described in JEP 261 [1]. This means that java.corba and the 6 EE modules aren't resolved by default and so it will look "as if" the types in these modules have been removed. More info on the JDK 9 dev mailing list [2]. A change that went into JDK 9 b102 is worth mentioning: JDK9: Remove stopThread RuntimePermission from the default java.policy In previous releases, untrusted code had the "stopThread" RuntimePermission granted by default. This permission allows untrusted code to call Thread.stop(), initiating an asynchronous ThreadDeath Error, on threads in the same thread group. Having a ThreadDeath Error thrown asynchronously is not something that trusted code should be expected to handle gracefully. The permission is no longer granted by default. Rgds,Rory [1] http://openjdk.java.net/jeps/261 [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-May/004309.html -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland |
|
From: Jeff A. <ja...@fa...> - 2016-05-17 19:08:58
|
On 17/05/2016 01:52, Stefan Richthofer wrote: > > The thread could create two (or more) PyBuffer-views of the same > object and hand both to various functions that read and write on them > without calling release (and thus trigger copy-back) inbetween. The > extension would expect if view 'A' was modified, view 'B' already > reflects this modification when passed to another function. The object can hand out a second reference to the same PyBuffer. (It's not required to, but the built-ins do.) > > The only way I can imagine an object with Java fields as storage > giving you a direct ByteBuffer on demand is to allocate one and copy > its state there. [...] effectively a change of implementation on the fly. > This is what I have in mind. Changing the backend on the fly shouldn't > be much more expensive than creating a copy, but would then save the > cost of copy-back and entire copy cost for future calls. Using the > bulk-set method of ByteBuffer this should be easy and efficient to do > (bulk-get to convert the other direction). The only infeasible > situation would be if an AS_DIRECT_NIO buffer was requested while an > array-backed buffer is exported and not yet released or vise versa. Aye, there's the rub, if at least one is writable. > In this case the request should just fail. I suppose for sake of > debugging we should add a verbose mode/flag that makes Jython print > out (or append it to the error message in bufferErrorFromSyndrome) the > exact reason why some buffer-request failed so a user is able to > identify the design flaw. Exceptions should always be that clear. However, it's not really a design flaw: hold a memoryview, and call a numpy function on the array: it's hardly faulty logic. > > This seems to bring us full circle to the behaviour of > Get<PrimitiveType>ArrayElements, except that I suppose the object > knows it has done it and can handle intervening access via the Java API > Since actual views to the same memory would be shared with (native) > extensions unlike Get<PrimitiveType>ArrayElements (in copy-case/no > array pinning) this would not break the case described above, where > multiple PyBuffer views to the same object are in the game. > I'm not sure what you mean by "full circle to the behaviour of > Get<PrimitiveType>ArrayElements", I meant in the sense that we have made a copy especially for C and may have to copy it back. You're correct that there are still a number of delicate problems to solve during the period the implementation has changed. Jeff > *Gesendet:* Montag, 16. Mai 2016 um 22:04 Uhr > *Von:* "Jeff Allen" <ja...@fa...> > *An:* "Stefan Richthofer" <Ste...@gm...> > *Cc:* "Jython Developers" <jyt...@li...> > *Betreff:* Re: [Jython-dev] Buffer protocol - direct vs. JVM ByteBuffers > > Thanks for that. So, the (possible) copy-back semantics of > Get<PrimitiveType>ArrayElements effectively make a direct buffer copy > of the contents. If the C-code runs in the thread of the Java > execution that calls it (or equivalently it is suspended) then to > first order the copy causes no problem. But it is not difficult to > cook up a scenario where another thread or call-back into Java sees a > different state from C. > > Alternatively, one uses the "critical" methods, and suffers > restrictions that are, I expect, unenforcible on arbitrary CPython > extension modules, such as being short and not yielding the CPU. > > I'm reminded of the relationship in CPython between C-code and > interpreted code, where the GIL must be held, proving all other > threads are "restubg" between instructions, and a context switch is > only allowed when surrounded by the appropriate magical incantations. > I think the Universe is trying to tell us something. > > The problem I see with the DIRECT_NIO flag is that one cannot expect > to choose, at the point of getting a PyBuffer, whether that buffer > should be direct or heap. The data that hold the state of an object > have a certain implementation in Java, and so the buffer will be a > heap buffer. Or one can imagine a PyObject whose state is always in a > direct ByteBuffer (representing an image mapped from disk, say) and > then the PyBuffer would always be direct. Just possibly objects whose > main purpose is to be native-friendly would have that implementation. > Just possibly, this is a thing you get to choose when the object is > constructed. > > The only way I can imagine an object with Java fields as storage > giving you a direct ByteBuffer on demand is to allocate one and copy > its state there. This seems to bring us full circle to the behaviour > of Get<PrimitiveType>ArrayElements , except that I suppose the object > knows it has done it and can handle intervening access via the Java > API ... effectively a change of implementation on the fly. > > Jeff Allen > On 15/05/2016 16:39, Stefan Richthofer wrote: > > Just an add-on to my recent post: > >It may depend on storage.hasArray(), but storage.isDirect() seems > to make no difference. > I think it is likely the JVM does not offer a backing array, if > the buffer is created as direct (i.e. these flags likely exclude > each other), because this would imply array pinning and all the > restrictions coming with it. I didn't test it though, but anyway > we cannot rely on the one or other behavior, as doc explicitly > does not guarantee a backing array for direct buffers, saying this > is "implementation specific". > *Gesendet:* Sonntag, 15. Mai 2016 um 11:57 Uhr > *Von:* "Jeff Allen" <ja...@fa...> > *An:* "Stefan Richthofer" <Ste...@gm...>, "Jython > Developers" <jyt...@li...> > *Betreff:* [Jython-dev] Buffer protocol - direct vs. JVM ByteBuffers > > Stefan: > > https://github.com/jythontools/jython/pull/39 > > What difference does it make in your use case whether a NIO > ByteBuffer is direct or non-direct? I can see why a client might > want to know which it had been given, but not why it might want an > exception raised in one or other case. > > Nothing I'm doing seems to depend on what kind of memory the > exporting object has, therefore on the implementation type of > ByteBuffer storage. It may depend on storage.hasArray(), but > storage.isDirect() seems to make no difference. > > Jeff > > -- > Jeff Allen > > |
|
From: Stefan R. <Ste...@gm...> - 2016-05-17 00:52:52
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>>So, the (possible) copy-back semantics of Get<PrimitiveType>ArrayElements effectively make a direct buffer copy of the contents</div> <div> </div> <div>Except that a direct buffer instantanously reflects modifications on Java-side</div> <div> </div> <div>>If the C-code runs in the thread of the Java execution that calls it (or equivalently it is suspended) then to first order the copy causes no problem.</div> <div> </div> <div>Good point: A single threaded evironment would (usually) not notice the difference between direct or copy-back semantics. Given that JyNI holds a native GIL and native extensions are usually designed in context of a GIL'ed environment chances are good that we would get away with the copy-back fallback for writable PyBuffer in the majority of cases.</div> <div><br/> Still, note that also even a single threaded setup could break this:<br/> The thread could create two (or more) PyBuffer-views of the same object and hand both to various functions that read and write on them without calling release (and thus trigger copy-back) inbetween. The extension would expect if view 'A' was modified, view 'B' already reflects this modification when passed to another function. One could argue this is an insane design, but I actually cannot assess what good reasons some programmer might have for this.</div> <div><br/> > The only way I can imagine an object with Java fields as storage giving you a direct ByteBuffer on demand is to allocate one and copy its state there. [...] effectively a change of implementation on the fly.</div> <div> </div> <div>This is what I have in mind. Changing the backend on the fly shouldn't be much more expensive than creating a copy, but would then save the cost of copy-back and entire copy cost for future calls. Using the bulk-set method of ByteBuffer this should be easy and efficient to do (bulk-get to convert the other direction). The only infeasible situation would be if an AS_DIRECT_NIO buffer was requested while an array-backed buffer is exported and not yet released or vise versa. In this case the request should just fail. I suppose for sake of debugging we should add a verbose mode/flag that makes Jython print out (or append it to the error message in bufferErrorFromSyndrome) the exact reason why some buffer-request failed so a user is able to identify the design flaw.</div> <div> </div> <div>> This seems to bring us full circle to the behaviour of Get<PrimitiveType>ArrayElements, except that I suppose the object knows it has done it and can handle intervening access via the Java API</div> <div> </div> <div>Since actual views to the same memory would be shared with (native) extensions unlike Get<PrimitiveType>ArrayElements (in copy-case/no array pinning) this would not break the case described above, where multiple PyBuffer views to the same object are in the game.</div> <div> </div> <div>I'm not sure what you mean by "full circle to the behaviour of Get<PrimitiveType>ArrayElements", so let me comprehend how I assume the fallback (in BaseBuffer etc) for non-array-backed ByteBuffer backend would take place:<br/> (gave it some thoughts recently)</div> <div> </div> <div>- use bulk-get to copy buffer content to a temporary array (maybe a reused one, but that's an optimization; also it might often be sufficient to copy a limited subsection of the buffer, which is another optimization)<br/> - perform on the temporary array just like one would usually do on the backing array<br/> - use bulk-set to copy-back the temporary array to the buffer<br/> - these operations should be glued together by a synchronized block (on the ByteBuffer backend) in order to appear like an atomical operation<br/> (this could actually still interfere with native buffer-access in multi-threaded case, but multiple threads writing to the same buffer would not end-up sanely anyway. (ByteBuffer does not prihibit this (e.g. by ConcurrentModificationException) does it?)<br/> (obviously the bulk-get can be skipped for write-only access and the bulk-set can be skipped for read-only access etc)</div> <div><br/> This would be somehow "full circle to the behaviour of Get<PrimitiveType>ArrayElements" but would move the copy-back issue to Java-side, which is good: On Java-side we have much better control of copy-back timing and corresponding thread synchronization, unlike inside a foreign C-extension. Also, Java-code would be aware of this semantics or use the AS_ARRAY flag, both of which would be fine.</div> <div> </div> <div> <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> Montag, 16. Mai 2016 um 22:04 Uhr<br/> <b>Von:</b> "Jeff Allen" <ja...@fa...><br/> <b>An:</b> "Stefan Richthofer" <Ste...@gm...><br/> <b>Cc:</b> "Jython Developers" <jyt...@li...><br/> <b>Betreff:</b> Re: [Jython-dev] Buffer protocol - direct vs. JVM ByteBuffers</div> <div> <div style="background-color: rgb(255,255,255);"> <p>Thanks for that. So, the (possible) copy-back semantics of <tt><span class="cEmphasis">Get<PrimitiveType>ArrayElements</span></tt> effectively make a direct buffer copy of the contents. If the C-code runs in the thread of the Java execution that calls it (or equivalently it is suspended) then to first order the copy causes no problem. But it is not difficult to cook up a scenario where another thread or call-back into Java sees a different state from C.</p> <p>Alternatively, one uses the "critical" methods, and suffers restrictions that are, I expect, unenforcible on arbitrary CPython extension modules, such as being short and not yielding the CPU.</p> <p>I'm reminded of the relationship in CPython between C-code and interpreted code, where the GIL must be held, proving all other threads are "restubg" between instructions, and a context switch is only allowed when surrounded by the appropriate magical incantations. I think the Universe is trying to tell us something.</p> <p>The problem I see with the <tt>DIRECT_NIO</tt> flag is that one cannot expect to choose, at the point of getting a PyBuffer, whether that buffer should be direct or heap. The data that hold the state of an object have a certain implementation in Java, and so the buffer will be a heap buffer. Or one can imagine a <tt>PyObject</tt> whose state is always in a direct <tt>ByteBuffer</tt> (representing an image mapped from disk, say) and then the <tt>PyBuffer</tt> would always be direct. Just possibly objects whose main purpose is to be native-friendly would have that implementation. Just possibly, this is a thing you get to choose when the object is constructed.</p> <p>The only way I can imagine an object with Java fields as storage giving you a direct <tt>ByteBuffer</tt> on demand is to allocate one and copy its state there. This seems to bring us full circle to the behaviour of <tt><span class="cEmphasis">Get<PrimitiveType>ArrayElements</span></tt> , except that I suppose the object knows it has done it and can handle intervening access via the Java API ... effectively a change of implementation on the fly.</p> <pre class="moz-signature">Jeff Allen</pre> <div class="moz-cite-prefix">On 15/05/2016 16:39, Stefan Richthofer wrote:</div> <blockquote> <div style="font-family: Verdana;font-size: 12.0px;"> <div> <div>Just an add-on to my recent post:</div> <div> </div> <div>>It may depend on <tt>storage.hasArray()</tt>, but <tt>storage.isDirect()</tt> seems to make no difference.</div> <div> </div> <div>I think it is likely the JVM does not offer a backing array, if the buffer is created as direct (i.e. these flags likely exclude each other), because this would imply array pinning and all the restrictions coming with it. I didn't test it though, but anyway we cannot rely on the one or other behavior, as doc explicitly does not guarantee a backing array for direct buffers, saying this is "implementation specific".</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> Sonntag, 15. Mai 2016 um 11:57 Uhr<br/> <b>Von:</b> "Jeff Allen" <a class="moz-txt-link-rfc2396E"><ja...@fa...></a><br/> <b>An:</b> "Stefan Richthofer" <a class="moz-txt-link-rfc2396E"><Ste...@gm...></a>, "Jython Developers" <a class="moz-txt-link-rfc2396E"><jyt...@li...></a><br/> <b>Betreff:</b> [Jython-dev] Buffer protocol - direct vs. JVM ByteBuffers</div> <div> <div style="background-color: rgb(255,255,255);"> <p>Stefan:</p> <p><a class="moz-txt-link-freetext" href="https://github.com/jythontools/jython/pull/39" target="_blank">https://github.com/jythontools/jython/pull/39</a></p> <p>What difference does it make in your use case whether a NIO ByteBuffer is direct or non-direct? I can see why a client might want to know which it had been given, but not why it might want an exception raised in one or other case.</p> <p>Nothing I'm doing seems to depend on what kind of memory the exporting object has, therefore on the implementation type of <tt>ByteBuffer storage</tt>. It may depend on <tt>storage.hasArray()</tt>, but <tt>storage.isDirect()</tt> seems to make no difference.</p> Jeff <pre class="moz-signature">-- Jeff Allen</pre> ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! <a class="moz-txt-link-freetext" href="https://ad.doubleclick.net/ddm/clk/304595813;131938128;j_______________________________________________" target="_blank">https://ad.doubleclick.net/ddm/clk/304595813;131938128;j_______________________________________________</a> Jython-dev mailing list <a class="moz-txt-link-abbreviated">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></div> </div> </div> </div> </div> </div> </blockquote> </div> </div> </div> </div> </div></div></body></html> |
|
From: Jeff A. <ja...@fa...> - 2016-05-16 20:04:37
|
Thanks for that. So, the (possible) copy-back semantics of Get<PrimitiveType>ArrayElements|| effectively make a direct buffer copy of the contents. If the C-code runs in the thread of the Java execution that calls it (or equivalently it is suspended) then to first order the copy causes no problem. But it is not difficult to cook up a scenario where another thread or call-back into Java sees a different state from C. Alternatively, one uses the "critical" methods, and suffers restrictions that are, I expect, unenforcible on arbitrary CPython extension modules, such as being short and not yielding the CPU. I'm reminded of the relationship in CPython between C-code and interpreted code, where the GIL must be held, proving all other threads are "restubg" between instructions, and a context switch is only allowed when surrounded by the appropriate magical incantations. I think the Universe is trying to tell us something. The problem I see with the DIRECT_NIO flag is that one cannot expect to choose, at the point of getting a PyBuffer, whether that buffer should be direct or heap. The data that hold the state of an object have a certain implementation in Java, and so the buffer will be a heap buffer. Or one can imagine a PyObject whose state is always in a direct ByteBuffer (representing an image mapped from disk, say) and then the PyBuffer would always be direct. Just possibly objects whose main purpose is to be native-friendly would have that implementation. Just possibly, this is a thing you get to choose when the object is constructed. The only way I can imagine an object with Java fields as storage giving you a direct ByteBuffer on demand is to allocate one and copy its state there. This seems to bring us full circle to the behaviour of Get<PrimitiveType>ArrayElements|| , except that I suppose the object knows it has done it and can handle intervening access via the Java API ... effectively a change of implementation on the fly. Jeff Allen On 15/05/2016 16:39, Stefan Richthofer wrote: > Just an add-on to my recent post: > >It may depend on storage.hasArray(), but storage.isDirect() seems to > make no difference. > I think it is likely the JVM does not offer a backing array, if the > buffer is created as direct (i.e. these flags likely exclude each > other), because this would imply array pinning and all the > restrictions coming with it. I didn't test it though, but anyway we > cannot rely on the one or other behavior, as doc explicitly does not > guarantee a backing array for direct buffers, saying this is > "implementation specific". > *Gesendet:* Sonntag, 15. Mai 2016 um 11:57 Uhr > *Von:* "Jeff Allen" <ja...@fa...> > *An:* "Stefan Richthofer" <Ste...@gm...>, "Jython > Developers" <jyt...@li...> > *Betreff:* [Jython-dev] Buffer protocol - direct vs. JVM ByteBuffers > > Stefan: > > https://github.com/jythontools/jython/pull/39 > > What difference does it make in your use case whether a NIO ByteBuffer > is direct or non-direct? I can see why a client might want to know > which it had been given, but not why it might want an exception raised > in one or other case. > > Nothing I'm doing seems to depend on what kind of memory the exporting > object has, therefore on the implementation type of ByteBuffer > storage. It may depend on storage.hasArray(), but storage.isDirect() > seems to make no difference. > > Jeff > -- > Jeff Allen > ------------------------------------------------------------------------------ > Mobile security can be enabling, not merely restricting. Employees who > bring their own devices (BYOD) to work are irked by the imposition of > MDM restrictions. Mobile Device Manager Plus allows you to control > only the apps on BYO-devices by containerizing them, leaving personal > data untouched! > https://ad.doubleclick.net/ddm/clk/304595813;131938128;j_______________________________________________ > Jython-dev mailing list Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
|
From: Stefan R. <Ste...@gm...> - 2016-05-15 15:39:46
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>Just an add-on to my recent post:</div> <div> </div> <div>>It may depend on <tt>storage.hasArray()</tt>, but <tt>storage.isDirect()</tt> seems to make no difference.</div> <div> </div> <div>I think it is likely the JVM does not offer a backing array, if the buffer is created as direct (i.e. these flags likely exclude each other), because this would imply array pinning and all the restrictions coming with it. I didn't test it though, but anyway we cannot rely on the one or other behavior, as doc explicitly does not guarantee a backing array for direct buffers, saying this is "implementation specific".</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> Sonntag, 15. Mai 2016 um 11:57 Uhr<br/> <b>Von:</b> "Jeff Allen" <ja...@fa...><br/> <b>An:</b> "Stefan Richthofer" <Ste...@gm...>, "Jython Developers" <jyt...@li...><br/> <b>Betreff:</b> [Jython-dev] Buffer protocol - direct vs. JVM ByteBuffers</div> <div name="quoted-content"> <div style="background-color: rgb(255,255,255);"> <p>Stefan:</p> <p><a class="moz-txt-link-freetext" href="https://github.com/jythontools/jython/pull/39" target="_blank">https://github.com/jythontools/jython/pull/39</a></p> <p>What difference does it make in your use case whether a NIO ByteBuffer is direct or non-direct? I can see why a client might want to know which it had been given, but not why it might want an exception raised in one or other case.</p> <p>Nothing I'm doing seems to depend on what kind of memory the exporting object has, therefore on the implementation type of <tt>ByteBuffer storage</tt>. It may depend on <tt>storage.hasArray()</tt>, but <tt>storage.isDirect()</tt> seems to make no difference.</p> Jeff <pre class="moz-signature">-- Jeff Allen</pre> ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! <a href="https://ad.doubleclick.net/ddm/clk/304595813;131938128;j_______________________________________________" target="_blank">https://ad.doubleclick.net/ddm/clk/304595813;131938128;j_______________________________________________</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> |
101 messages has been excluded from this view by a project administrator.
