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
(7) |
Oct
|
Nov
|
Dec
|
|
From: Jython tracker <status@bu...> - 2016-09-23 16:10:22
|
ACTIVITY SUMMARY (2016-09-16 - 2016-09-23) 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 2254 ( +0) total 2539 ( +0) Open issues with patches: 27 Most recent 15 issues with no replies (15) ========================================== #2520: Jython does NOT support socket.listen(0) for accepting only on http://bugs.jython.org/issue2520 #2512: Values in built-in modules's __dict__ are â<reflected field http://bugs.jython.org/issue2512 #2511: Percent operator calls __getattr__('__getitem__') http://bugs.jython.org/issue2511 #2510: TypeError when monkey-patching time.time with an unbound funct http://bugs.jython.org/issue2510 #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 #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 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #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) ============================================= #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 #1646: Proxy getInterface not change for more PyObject http://bugs.jython.org/issue1646 |
|
From: Rory O'Donnell <rory.odonnell@or...> - 2016-09-20 10:20:06
|
Hi Alan, Early Access b136 <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+136.html>;. Early Access b136 <https://jdk9.java.net/jigsaw/>; (#5506) for JDK 9 with Project Jigsaw is available on java.net, summary of changes are listed here <http://www.java.net/download/java/jigsaw/archive/136/binaries/jdk-9+136.html>;. There have been a number of fixes to bugs reported by Open Source projects since the last availability email : * 8165723 - b136 - core-libs JarFile::isMultiRelease() method returns false when it should return true * 8165116 - b136 - xml redirect function is not allowed even with enableExtensionFunctions NOTE:- Build 135 included a fix for JDK-8161016 which *has introduced a behavioral change to HttpURLConnection, more info:* The behavior of HttpURLConnection when using a ProxySelector has been modified with this JDK release. Currently, HttpURLConnection.connect() call would fallback to a DIRECT connection attempt if the configured proxy/proxies failed to make a connection. This release introduces a change whereby no DIRECT connection will be attempted in such a scenario. Instead, the HttpURLConnection.connect() method will fail and throw an IOException which occurred from the last proxy tested. This behavior now matches with the HTTP connections made by popular web browsers. But this change will bring compatibility issues for the applications expecting a DIRECT connection when a proxy server is down or when wrong proxies are provided. * JDK 9 Outreach Survey* In order to encourage and receive additional feedback from developers testing their applications with JDK 9, the OpenJDK Quality Outreach effort has put together a very brief survey about your experiences with JDK 9 so far. It is available at***https://www.surveymonkey.de/r/JDK9EA* We would love to hear feedback from you! Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland |
|
From: Jython tracker <status@bu...> - 2016-09-16 16:10:21
|
ACTIVITY SUMMARY (2016-09-09 - 2016-09-16) 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 ( -6) closed 2254 ( +6) total 2539 ( +0) Open issues with patches: 27 Most recent 15 issues with no replies (15) ========================================== #2520: Jython does support socket.listen(0) for accepting only one co http://bugs.jython.org/issue2520 #2512: Values in built-in modules's __dict__ are â<reflected field http://bugs.jython.org/issue2512 #2511: Percent operator calls __getattr__('__getitem__') http://bugs.jython.org/issue2511 #2510: TypeError when monkey-patching time.time with an unbound funct http://bugs.jython.org/issue2510 #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 #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 #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) ============================================= #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 #1646: Proxy getInterface not change for more PyObject http://bugs.jython.org/issue1646 Issues closed (1) ================= #2485: getArray method for PyList, PyTuple throws java.lang.StackOve http://bugs.jython.org/issue2485 closed by zyasoft |
|
From: Jython tracker <status@bu...> - 2016-09-09 16:10:25
|
ACTIVITY SUMMARY (2016-09-02 - 2016-09-09) 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 291 ( -4) closed 2248 ( +7) total 2539 ( +3) Open issues with patches: 27 Issues opened (3) ================= #2518: Multiple failures in test_xml_etree_jy http://bugs.jython.org/issue2518 opened by jeff.allen #2519: Hangs in test.test_gc_jy under regrtest http://bugs.jython.org/issue2519 opened by jeff.allen #2520: Jython does support socket.listen(0) for accepting only one co http://bugs.jython.org/issue2520 opened by zyasoft Most recent 15 issues with no replies (15) ========================================== #2520: Jython does support socket.listen(0) for accepting only one co http://bugs.jython.org/issue2520 #2512: Values in built-in modules's __dict__ are â<reflected field http://bugs.jython.org/issue2512 #2511: Percent operator calls __getattr__('__getitem__') http://bugs.jython.org/issue2511 #2510: Crash after monkey-patching time.time with an unbound function http://bugs.jython.org/issue2510 #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 #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 #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) ============================================= #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 #1646: Proxy getInterface not change for more PyObject http://bugs.jython.org/issue1646 Top 10 most discussed issues (2) ================================ #2413: ElementTree.write doesn't close files if used with invalid enc http://bugs.jython.org/issue2413 3 msgs #2517: Showers of stack dumps from netty finalization http://bugs.jython.org/issue2517 3 msgs Issues closed (3) ================= #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 closed by zyasoft #2481: Update urllib2.py from 2.7.11 http://bugs.jython.org/issue2481 closed by zyasoft #2498: Jython 2.7.0 pdb library (jump command) is not working http://bugs.jython.org/issue2498 closed by zyasoft |
|
From: Oti <ohumbel@gm...> - 2016-09-08 16:29:18
|
Hi all, my provider announced a 2 hours scheduled downtime of the logs ( http://www.extreme.st/jython.extreme.st/irclogs/index.php), starting at: Zürich (Switzerland - Zurich) Friday, 9 September 2016, 23:00:00 CEST UTC+2 hours Los Angeles (USA - California) Friday, 9 September 2016, 14:00:00 PDT UTC-7 hours Corresponding UTC (GMT) Friday, 9 September 2016, 21:00:00 During the 2 hours, the logs still will be recorded. I expect them to be fully visible again afterwards. Best wishes, Oti. |
|
From: Rory O'Donnell <rory.odonnell@or...> - 2016-09-05 17:30:21
|
Hi Alan, Early Access b134 <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+134.html>;. There have been a number of fixes , since the last availability email , to bugs reported by Open Source projects : * 8156841 sun.security.pkcs11.SunPKCS11 poller thread retains a strong reference to the context class loader * 8146961 Fix PermGen memory leaks caused by static final Exceptions * 8163353 NPE in ConcurrentHashMap.removeAll() * 8160328 ClassCastException: sun.awt.image.BufImgSurfaceData cannot be cast to sun.java2d.xr.XRSurfaceData after xrandr change output Secondly, there are a number of interesting items to bring to our attention * JDK 9 Rampdown Phase 1: Process proposal [1] * The Java team has published the “Oracle JRE and JDK Cryptographic Roadmap” [2] java.com/cryptoroadmap <http://java.com/cryptoroadmap>; * The Quality Report for September 2016 is now available [3], thank you for your continued support! Highlights from the Quality Report for September : * 21 new Open Source projects have joined the Outreach program * Projects filed 35 new issues in the JDK Bug System, this is almost double the number of bugs in the previous six months! * Continuing to provide excellent feedback via the OpenJDK dev mailing lists Thank you! Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html [2] java.com/cryptoroadmap <http://java.com/cryptoroadmap>; [3] https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+September+2016 -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland |
|
From: Jython tracker <status@bu...> - 2016-09-02 16:10:24
|
ACTIVITY SUMMARY (2016-08-26 - 2016-09-02) 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 295 ( +2) closed 2241 ( +0) total 2536 ( +2) Open issues with patches: 28 Issues opened (2) ================= #2516: _get_open_ssl_key_manager tries to validate that the private a http://bugs.jython.org/issue2516 opened by darjus #2517: Showers of stack dumps from netty finalization http://bugs.jython.org/issue2517 opened by jeff.allen Most recent 15 issues with no replies (15) ========================================== #2517: Showers of stack dumps from netty finalization http://bugs.jython.org/issue2517 #2512: Values in built-in modules's __dict__ are â<reflected field http://bugs.jython.org/issue2512 #2511: Percent operator calls __getattr__('__getitem__') http://bugs.jython.org/issue2511 #2510: Crash after monkey-patching time.time with an unbound function http://bugs.jython.org/issue2510 #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 #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 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 Top 10 most discussed issues (1) ================================ #2443: java.util.Map derived classes lack iterkeys, itervalues method http://bugs.jython.org/issue2443 3 msgs |
|
From: Jeff Allen <ja.py@fa...> - 2016-08-29 12:41:10
|
No problem with the established consensus on os.name, which I believe to
be that we are stuck with "java" until Jython 3.x.
I believe we need to express three dimensions here:
1. what to expect about the names of files. This should be os.name, but
make do with os._name until 3.x.
2. what to expect from the real machine.
3. what virtual machine (or runtime) is executing my code. The type
should be platform.python_implementation().
Now, the answer to question 2 will be assumed by programmers coming from
CPython to be platform.system and the first element of the result of
platform.uname(). The documentation explicitly allows "Java" as a
legitimate value
(https://docs.python.org/3/library/platform.html#platform.system). My
first answer to Stefan was based on that documentation.
But now I think this is to repeat the mistake we made with os.name, and
the documentation hint is wrong: it were better platform.system gave you
the OS underneath. You have a couple of other ways to find out it's Java
or Jython. If I'm right about this, maybe platform.system should remain
consistent with os.name; or maybe it should take the noble course from
the start.
Jeff
Jeff Allen
On 19/08/2016 03:24, Darjus Loktevic wrote:
> Agreed,
>
> Let's make this change in Jython3. We really cannot break this for
> Jython2.
>
> On Thu, Aug 18, 2016 at 3:49 PM Jeff Allen <ja.py@...
> <mailto:ja.py@...>> wrote:
>
> I agree with all this. As I said initially:
>
> It seems clear platform.uname should be consistent with
> platform.system,
> platform.node, and so on. The documentation of platform.system
> explicitly mentions 'Java' as an expected return. Not clear that it
> should be consistent with os.uname.
>
> I also agree it is a pain that os.name <http://os.name>; should not
> reflect the real "disk
> operating system" when so much code uses it like that. I think I saw
> that this change has already been made in Jython 3. (Did I dream it?)
>
> However, I seem to observe (and it may be old code) that os.name
> <http://os.name>; gets
> used in two ways: in one place to decide what functions might be
> available, and in another to decide whether paths like "C:\Users"
> would
> be valid. These uses conflict when you throw in jnr-posix. Perhaps,
> against one's initial instincts, the availability of functions in
> the os
> module is best inferred from platform.name <http://platform.name>;
> rather than os.name <http://os.name>;.
>
> Jeff
>
> Jeff Allen
>
> On 17/08/2016 17:28, Jim Baker wrote:
> > On Wed, Aug 17, 2016 at 9:22 AM, Stefan Richthofer
> > <Stefan.Richthofer@... <mailto:Stefan.Richthofer@...>
> <mailto:Stefan.Richthofer@...
> <mailto:Stefan.Richthofer@...>>> wrote:
> >
> > Hey Jeff,
> > thanks for your reply!
> >
> > I agree that in theory, os.uname and platform.uname should be
> > consistent.
> > And also platform.system with uname. However in practice, IMO it
> > would cause much less trouble with not-Jython-aware modules if
> > uname would provide native info rather than JVM-info.
> Jython-aware
> > modules can obtain JVM-info from platform.java_ver anyway.
> On the
> > other hand platform.uname always returned JVM-info in Jython
> until
> > now, so there might be Jython-aware code out there relying
> on this.
> > So as a compromise I'd suggest to let platform.uname behave like
> > it always used to and os.uname provide native info such that
> > non-Jython-aware modules have higher chance to work (especially
> > relevant in JyNI; I wouldn't want to monkeypatch this!).
> os.uname
> > should be save for existing Jython-aware modules, since it
> didn't
> > exist at all in Jython prior to 2.7.1.
> >
> >
> > +1, let's make this distinction. Keep os.uname with the new change;
> > and make platform.uname go back to being Java information. This
> is why
> > we have the platform module, vs the os module.
> >
> > I would keep this distinction for Jython 3.
> >
> >
> > (It's already a constant pain that os.name <http://os.name>;
> <http://os.name>; is
> > 'java' and Alex Grönholm once pointed out in IRC this would
> switch
> > to CPython behavior in Jython 3. IIRC this currently breaks
> pip in
> > Jython on Windows. Maybe this can be fixed with a hack I use in
> > JyNI, but that's rather a story for Jython 2.7.2.)
> >
> >
> > Agreed about the constant pain.
> >
> > If we had the chance to go back in time to fix this for 2.7.0, I
> would
> > have made os.name <http://os.name>; <http://os.name>; be the
> underlying OS (eg 'posix'
> > instead of 'java'). The os module should be about the underlying
> OS -
> > it mostly is. So definitely we should fix for Jython 3.
> >
> >
> > Summary
> > If there are no objections I will make
> > - os.uname provide native platform info (for practicability)
> > - platform.uname provide JVM-info (for backward-compatibility)
> > We still need to more confidently decide how os.uname should
> > behave on Windows (however keeping current variant shouldn't be
> > too bad I suppose).
> >
> >
> > +1
> >
> > Supporting os.uname on Windows make sense.
> >
> > - Jim
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> <mailto:Jython-dev@...>
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
|
|
From: Darjus Loktevic <darjus@gm...> - 2016-08-29 12:10:34
|
Hey Guys, Just want to let you know I'll be traveling without a computer till 13th and won't be responding emails :) Cheers, Darjus |
|
From: Jython tracker <status@bu...> - 2016-08-26 16:10:23
|
ACTIVITY SUMMARY (2016-08-19 - 2016-08-26) 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 293 ( -1) closed 2241 ( +2) total 2534 ( +1) Open issues with patches: 28 Issues opened (1) ================= #2515: typing module doesn't import http://bugs.jython.org/issue2515 opened by stefan.richthofer Most recent 15 issues with no replies (15) ========================================== #2512: Values in built-in modules's __dict__ are â<reflected field http://bugs.jython.org/issue2512 #2511: Percent operator calls __getattr__('__getitem__') http://bugs.jython.org/issue2511 #2510: Crash after monkey-patching time.time with an unbound function http://bugs.jython.org/issue2510 #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 #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 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 Top 10 most discussed issues (2) ================================ #2513: Standard output is mixed up if Python scripts are evaluated in http://bugs.jython.org/issue2513 4 msgs #2505: PySystemState is lost http://bugs.jython.org/issue2505 3 msgs Issues closed (1) ================= #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 closed by zyasoft |
|
From: Jim Baker <jim.baker@py...> - 2016-08-24 20:13:29
|
On Wed, Aug 24, 2016 at 3:49 PM, Jeff Allen <ja.py@...> wrote: > Good. Thanks for being quick. > > Gah, sorry about the line endings! I have them visible in the IDE too, > so no excuse. From the fact that they're mixed, it must've happened when > I used notepad as a ... note pad. I'll de-nit. > No worries - I'm just glad it was visible in how I was looking at the diff. My one suggestion: please squash this diff into one commit, especially because the history is fairly extended. I can do that for you based on your Bitbucket repo if you want. > > NEWS entry ... above the "Jython 2.7.1rc" heading, ready for an rc2 > heading above that when we get there, right? > Actually under the 2.7.1rc heading (recently added). I know we talked about the 2.7.1 RC for the longest time, but this was delayed by a variety of must fix bugs - most notably the work to remove a race condition in Python type <=> java class mappings that was recently fixed. FWIW, here's my working list of such bugs, although it needs one more round of triage: bit.ly/jython-triage-2_7_1 Next week I'm back from week of OpenStack events, so that's will be a good time to really wrap 2.7.1 up. - Jim |
|
From: Jeff Allen <ja.py@fa...> - 2016-08-24 19:50:06
|
Good. Thanks for being quick. Gah, sorry about the line endings! I have them visible in the IDE too, so no excuse. From the fact that they're mixed, it must've happened when I used notepad as a ... note pad. I'll de-nit. NEWS entry ... above the "Jython 2.7.1rc" heading, ready for an rc2 heading above that when we get there, right? Jeff Jeff Allen On 24/08/2016 20:29, Jim Baker wrote: > Jeff, > > I think the change looks good other than one small nit - the following > new files use Windows-style line endings: > > * src/org/python/core/buffer/Base1DBuffer.java > * src/org/python/core/buffer/BaseArrayBuffer.java > * src/org/python/core/buffer/BaseNIOBuffer.java > * src/org/python/core/buffer/SimpleNIOBuffer.java > * src/org/python/core/buffer/Strided1DNIOBuffer.java > * tests/java/org/python/core/ByteBufferTestSupport.java > * tests/java/org/python/core/PyBufferNIOTest.java > > > It makes sense for me to get this into the long delayed 2.7.1 - I do > not see this change impacting any users, and it will clean up buffer > protocol support. The alternative is that we have this change sit > around and "bit rot" - not a good situation! > > Please merge away, with an updated NEWS entry, once the line endings > are fixed. > > Thanks! > > - Jim > > > On Wed, Aug 24, 2016 at 1:40 PM, Jim Baker <jim.baker@... > <mailto:jim.baker@...>> wrote: > > Jeff, > > Sorry, thanks for pinging about this. I will take a look today and > get back to you on that change. > > Other people on this list: feel free to bug me if I miss > something. I'm a very poor implementation of a select loop - > always dropping things... But retries usually get through. > > - Jim > > On Wed, Aug 24, 2016 at 4:02 AM, Jeff Allen <ja.py@... > <mailto:ja.py@...>> wrote: > > Jim & all: > > I feel this has been sitting off to one side long enough. Do > we feel safe that I can merge the underlying work? > > https://bitbucket.org/tournesol/jython-nio > <https://bitbucket.org/tournesol/jython-nio>; > > I'll write a short paragraph for NEWS as the last change. On a > trivial matter of technique, that para goes above the "Jython > 2.7.1rc" heading, ready for an rc2 heading above that when we > get there, right? > > Jeff > > Jeff Allen > > > On 19/07/2016 21:00, Jeff Allen wrote: > > Thanks Stefan: nothing obviously crazy about the concept then. > > I'll take others' advice (Jim?) on whether this kind of > change is too > much for 2.7.1, or feels safe. > > Concerning loops with calls in them, there's always an > implementation > like that near the base of the hierarchy so that the > non-contiguous case > is catered for, then the option (which I like to take up) > of using a > bulk method in the contiguous sub-class. If we suddenly > wanted to > support CopyTo/From ByteBuffer in the API, implementing it > efficiently > could follow along. > > Main thing is you have your buffer protocol interface onto > non-heap > storage to try when you can. > > Jeff > > Jeff Allen > > On 17/07/2016 15:26, Stefan Richthofer wrote: > > Hello Jeff, > > sorry for the delay. I was (and still am) busy with > adding NumPy support and it turned out that NumPy is > okay with PyMemoryView_FromObject returning null for > now (I suppose it has a fallback for that). It > actually does call that method which is why I thought > buffer protocol (which PyMemoryView_FromObject is > based on) would be an urgent need for NumPy support. > Of course I still want to add buffer protocol to JyNI, > but won't find time to look at this before NumPy > support moved on some more. So I did not yet take a > detailed look at your work. However my main concern > there would be to avoid that any index-iterating > (NIO-bridge-)method would perform method calls within > a loop, but instead is implemented using bulk-access > methods. If this is already the case I would most > likely have no further concerns. > Thanks for adding getObj(); this is useful in any case. > > Do you think this would be bloat, nice-to-have, or > really useful for what you were hoping to do? > > This sounds like it is mainly relevant for > Java-integration and not so much for JyNI. > Spontaneously I'd give it a "nice to have". > > To give you some definite clue regarding my > time-management: I will resume work on > BufferProtocol-front after > a) Jython 2.7.1 was released > b) JyNI 2.7-alpha.4 was released. > > > Best, > > Stefan > > > Gesendet: Freitag, 15. Juli 2016 um 09:42 Uhr > Von: "Jeff Allen" <ja.py@... > <mailto:ja.py@...>> > An: "Stefan Richthofer" <Stefan.Richthofer@... > <mailto:Stefan.Richthofer@...>> > Cc: "Jython Developers" > <jython-dev@... > <mailto:jython-dev@...>> > Betreff: Re: [Jython-dev] Jython buffer protocol > > 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.py@... > <mailto:ja.py@...>> > An: "Stefan Richthofer" > <Stefan.Richthofer@... > <mailto:Stefan.Richthofer@...>> > Cc: "Jython Developers" > <jython-dev@... > <mailto:jython-dev@...>> > 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 > <https://bitbucket.org/tournesol/jython-nio>; > > <snip> > > > ------------------------------------------------------------------------------ > 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.http://sdm.link/zohodev2dev > <http://sdm.link/zohodev2dev>; > _______________________________________________ > Jython-dev mailing list > Jython-dev@... > <mailto:Jython-dev@...> > https://lists.sourceforge.net/lists/listinfo/jython-dev > <https://lists.sourceforge.net/lists/listinfo/jython-dev>; > > > > |
|
From: Jim Baker <jim.baker@py...> - 2016-08-24 19:29:28
|
Jeff, I think the change looks good other than one small nit - the following new files use Windows-style line endings: - src/org/python/core/buffer/Base1DBuffer.java - src/org/python/core/buffer/BaseArrayBuffer.java - src/org/python/core/buffer/BaseNIOBuffer.java - src/org/python/core/buffer/SimpleNIOBuffer.java - src/org/python/core/buffer/Strided1DNIOBuffer.java - tests/java/org/python/core/ByteBufferTestSupport.java - tests/java/org/python/core/PyBufferNIOTest.java It makes sense for me to get this into the long delayed 2.7.1 - I do not see this change impacting any users, and it will clean up buffer protocol support. The alternative is that we have this change sit around and "bit rot" - not a good situation! Please merge away, with an updated NEWS entry, once the line endings are fixed. Thanks! - Jim On Wed, Aug 24, 2016 at 1:40 PM, Jim Baker <jim.baker@...> wrote: > Jeff, > > Sorry, thanks for pinging about this. I will take a look today and get > back to you on that change. > > Other people on this list: feel free to bug me if I miss something. I'm a > very poor implementation of a select loop - always dropping things... But > retries usually get through. > > - Jim > > On Wed, Aug 24, 2016 at 4:02 AM, Jeff Allen <ja.py@...> wrote: > >> Jim & all: >> >> I feel this has been sitting off to one side long enough. Do we feel safe >> that I can merge the underlying work? >> >> https://bitbucket.org/tournesol/jython-nio >> >> I'll write a short paragraph for NEWS as the last change. On a trivial >> matter of technique, that para goes above the "Jython 2.7.1rc" heading, >> ready for an rc2 heading above that when we get there, right? >> >> Jeff >> >> Jeff Allen >> >> >> On 19/07/2016 21:00, Jeff Allen wrote: >> >>> Thanks Stefan: nothing obviously crazy about the concept then. >>> >>> I'll take others' advice (Jim?) on whether this kind of change is too >>> much for 2.7.1, or feels safe. >>> >>> Concerning loops with calls in them, there's always an implementation >>> like that near the base of the hierarchy so that the non-contiguous case >>> is catered for, then the option (which I like to take up) of using a >>> bulk method in the contiguous sub-class. If we suddenly wanted to >>> support CopyTo/From ByteBuffer in the API, implementing it efficiently >>> could follow along. >>> >>> Main thing is you have your buffer protocol interface onto non-heap >>> storage to try when you can. >>> >>> Jeff >>> >>> Jeff Allen >>> >>> On 17/07/2016 15:26, Stefan Richthofer wrote: >>> >>>> Hello Jeff, >>>> >>>> sorry for the delay. I was (and still am) busy with adding NumPy >>>> support and it turned out that NumPy is okay with PyMemoryView_FromObject >>>> returning null for now (I suppose it has a fallback for that). It actually >>>> does call that method which is why I thought buffer protocol (which >>>> PyMemoryView_FromObject is based on) would be an urgent need for NumPy >>>> support. Of course I still want to add buffer protocol to JyNI, but won't >>>> find time to look at this before NumPy support moved on some more. So I did >>>> not yet take a detailed look at your work. However my main concern there >>>> would be to avoid that any index-iterating (NIO-bridge-)method would >>>> perform method calls within a loop, but instead is implemented using >>>> bulk-access methods. If this is already the case I would most likely have >>>> no further concerns. >>>> Thanks for adding getObj(); this is useful in any case. >>>> >>>> Do you think this would be bloat, nice-to-have, or really useful for >>>>> what you were hoping to do? >>>>> >>>> This sounds like it is mainly relevant for Java-integration and not so >>>> much for JyNI. Spontaneously I'd give it a "nice to have". >>>> >>>> To give you some definite clue regarding my time-management: I will >>>> resume work on BufferProtocol-front after >>>> a) Jython 2.7.1 was released >>>> b) JyNI 2.7-alpha.4 was released. >>>> >>>> >>>> Best, >>>> >>>> Stefan >>>> >>>> >>>> Gesendet: Freitag, 15. Juli 2016 um 09:42 Uhr >>>>> Von: "Jeff Allen" <ja.py@...> >>>>> An: "Stefan Richthofer" <Stefan.Richthofer@...> >>>>> Cc: "Jython Developers" <jython-dev@...> >>>>> Betreff: Re: [Jython-dev] Jython buffer protocol >>>>> >>>>> 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.py@...> >>>>>>> An: "Stefan Richthofer" <Stefan.Richthofer@...> >>>>>>> Cc: "Jython Developers" <jython-dev@...> >>>>>>> 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> >>>>> >>>>> >>> ------------------------------------------------------------ >>> ------------------ >>> 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.http://sdm.link/zohodev2dev >>> _______________________________________________ >>> Jython-dev mailing list >>> Jython-dev@... >>> https://lists.sourceforge.net/lists/listinfo/jython-dev >>> >>> >> > |
|
From: Jim Baker <jim.baker@py...> - 2016-08-24 17:41:18
|
Jeff, Sorry, thanks for pinging about this. I will take a look today and get back to you on that change. Other people on this list: feel free to bug me if I miss something. I'm a very poor implementation of a select loop - always dropping things... But retries usually get through. - Jim On Wed, Aug 24, 2016 at 4:02 AM, Jeff Allen <ja.py@...> wrote: > Jim & all: > > I feel this has been sitting off to one side long enough. Do we feel safe > that I can merge the underlying work? > > https://bitbucket.org/tournesol/jython-nio > > I'll write a short paragraph for NEWS as the last change. On a trivial > matter of technique, that para goes above the "Jython 2.7.1rc" heading, > ready for an rc2 heading above that when we get there, right? > > Jeff > > Jeff Allen > > > On 19/07/2016 21:00, Jeff Allen wrote: > >> Thanks Stefan: nothing obviously crazy about the concept then. >> >> I'll take others' advice (Jim?) on whether this kind of change is too >> much for 2.7.1, or feels safe. >> >> Concerning loops with calls in them, there's always an implementation >> like that near the base of the hierarchy so that the non-contiguous case >> is catered for, then the option (which I like to take up) of using a >> bulk method in the contiguous sub-class. If we suddenly wanted to >> support CopyTo/From ByteBuffer in the API, implementing it efficiently >> could follow along. >> >> Main thing is you have your buffer protocol interface onto non-heap >> storage to try when you can. >> >> Jeff >> >> Jeff Allen >> >> On 17/07/2016 15:26, Stefan Richthofer wrote: >> >>> Hello Jeff, >>> >>> sorry for the delay. I was (and still am) busy with adding NumPy support >>> and it turned out that NumPy is okay with PyMemoryView_FromObject returning >>> null for now (I suppose it has a fallback for that). It actually does call >>> that method which is why I thought buffer protocol (which >>> PyMemoryView_FromObject is based on) would be an urgent need for NumPy >>> support. Of course I still want to add buffer protocol to JyNI, but won't >>> find time to look at this before NumPy support moved on some more. So I did >>> not yet take a detailed look at your work. However my main concern there >>> would be to avoid that any index-iterating (NIO-bridge-)method would >>> perform method calls within a loop, but instead is implemented using >>> bulk-access methods. If this is already the case I would most likely have >>> no further concerns. >>> Thanks for adding getObj(); this is useful in any case. >>> >>> Do you think this would be bloat, nice-to-have, or really useful for >>>> what you were hoping to do? >>>> >>> This sounds like it is mainly relevant for Java-integration and not so >>> much for JyNI. Spontaneously I'd give it a "nice to have". >>> >>> To give you some definite clue regarding my time-management: I will >>> resume work on BufferProtocol-front after >>> a) Jython 2.7.1 was released >>> b) JyNI 2.7-alpha.4 was released. >>> >>> >>> Best, >>> >>> Stefan >>> >>> >>> Gesendet: Freitag, 15. Juli 2016 um 09:42 Uhr >>>> Von: "Jeff Allen" <ja.py@...> >>>> An: "Stefan Richthofer" <Stefan.Richthofer@...> >>>> Cc: "Jython Developers" <jython-dev@...> >>>> Betreff: Re: [Jython-dev] Jython buffer protocol >>>> >>>> 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.py@...> >>>>>> An: "Stefan Richthofer" <Stefan.Richthofer@...> >>>>>> Cc: "Jython Developers" <jython-dev@...> >>>>>> 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> >>>> >>>> >> ------------------------------------------------------------ >> ------------------ >> 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.http://sdm.link/zohodev2dev >> _______________________________________________ >> Jython-dev mailing list >> Jython-dev@... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> >> > |
|
From: Jeff Allen <ja.py@fa...> - 2016-08-24 08:02:31
|
Jim & all: I feel this has been sitting off to one side long enough. Do we feel safe that I can merge the underlying work? https://bitbucket.org/tournesol/jython-nio I'll write a short paragraph for NEWS as the last change. On a trivial matter of technique, that para goes above the "Jython 2.7.1rc" heading, ready for an rc2 heading above that when we get there, right? Jeff Jeff Allen On 19/07/2016 21:00, Jeff Allen wrote: > Thanks Stefan: nothing obviously crazy about the concept then. > > I'll take others' advice (Jim?) on whether this kind of change is too > much for 2.7.1, or feels safe. > > Concerning loops with calls in them, there's always an implementation > like that near the base of the hierarchy so that the non-contiguous case > is catered for, then the option (which I like to take up) of using a > bulk method in the contiguous sub-class. If we suddenly wanted to > support CopyTo/From ByteBuffer in the API, implementing it efficiently > could follow along. > > Main thing is you have your buffer protocol interface onto non-heap > storage to try when you can. > > Jeff > > Jeff Allen > > On 17/07/2016 15:26, Stefan Richthofer wrote: >> Hello Jeff, >> >> sorry for the delay. I was (and still am) busy with adding NumPy support and it turned out that NumPy is okay with PyMemoryView_FromObject returning null for now (I suppose it has a fallback for that). It actually does call that method which is why I thought buffer protocol (which PyMemoryView_FromObject is based on) would be an urgent need for NumPy support. Of course I still want to add buffer protocol to JyNI, but won't find time to look at this before NumPy support moved on some more. So I did not yet take a detailed look at your work. However my main concern there would be to avoid that any index-iterating (NIO-bridge-)method would perform method calls within a loop, but instead is implemented using bulk-access methods. If this is already the case I would most likely have no further concerns. >> Thanks for adding getObj(); this is useful in any case. >> >>> Do you think this would be bloat, nice-to-have, or really useful for what you were hoping to do? >> This sounds like it is mainly relevant for Java-integration and not so much for JyNI. Spontaneously I'd give it a "nice to have". >> >> To give you some definite clue regarding my time-management: I will resume work on BufferProtocol-front after >> a) Jython 2.7.1 was released >> b) JyNI 2.7-alpha.4 was released. >> >> >> Best, >> >> Stefan >> >> >>> Gesendet: Freitag, 15. Juli 2016 um 09:42 Uhr >>> Von: "Jeff Allen" <ja.py@...> >>> An: "Stefan Richthofer" <Stefan.Richthofer@...> >>> Cc: "Jython Developers" <jython-dev@...> >>> Betreff: Re: [Jython-dev] Jython buffer protocol >>> >>> 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.py@...> >>>>> An: "Stefan Richthofer" <Stefan.Richthofer@...> >>>>> Cc: "Jython Developers" <jython-dev@...> >>>>> 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> >>> > > ------------------------------------------------------------------------------ > 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.http://sdm.link/zohodev2dev > _______________________________________________ > Jython-dev mailing list > Jython-dev@... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Jeff Allen <ja.py@fa...> - 2016-08-24 07:53:10
|
+1 for this. I write that tentatively because I only got my first taste of Gradle only this week. However, I'm no great fan of making human beings write XML and the Gradle DSL looks better to me at the moment. Jeff Allen On 19/08/2016 03:21, Darjus Loktevic wrote: > Might be useful for us as we have plans for moving away from Ant to > Gradle. Also would be useful for Jython users managing Python and Java > dependencies together > https://engineering.linkedin.com/blog/2016/08/introducing--py-gradle--an-open-source-python-plugin-for-gradle > |
|
From: Jython tracker <status@bu...> - 2016-08-19 16:10:23
|
ACTIVITY SUMMARY (2016-08-12 - 2016-08-19) 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 294 ( +1) closed 2239 ( +0) total 2533 ( +1) Open issues with patches: 28 Issues opened (1) ================= #2514: Jython Class.__subclasses__() does not match Python output (no http://bugs.jython.org/issue2514 opened by Myles Most recent 15 issues with no replies (15) ========================================== #2512: Values in built-in modules's __dict__ are â<reflected field http://bugs.jython.org/issue2512 #2511: Percent operator calls __getattr__('__getitem__') http://bugs.jython.org/issue2511 #2510: Crash after monkey-patching time.time with an unbound function http://bugs.jython.org/issue2510 #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 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 Top 10 most discussed issues (1) ================================ #2514: Jython Class.__subclasses__() does not match Python output (no http://bugs.jython.org/issue2514 3 msgs |
|
From: Jim Baker <jim.baker@py...> - 2016-08-19 15:06:09
|
Darjus, Thanks for taking a look at this. I believe the problem has been surfaced by the upgrade to Netty 4.1, which is giving us more feedback on a resource leak in test_socket. It's not the send fix itself. The solution to any Netty problem is to add another listener :), and joking aside, that should likely be the case here. - Jim On Fri, Aug 19, 2016 at 4:16 AM, Darjus Loktevic <darjus@...> wrote: > Hey Nick, > > Looks like your socket.send change broke the regregression tests. It seems > that something is leaking/isn't being cleaned up as expected if the address > is still in use. Would appreciate you taking a look at this. > > https://circleci.com/gh/jythontools/jython/tree/master > > Cheers, > Darjus > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > Jython-dev mailing list > Jython-dev@... > https://lists.sourceforge.net/lists/listinfo/jython-dev > > |
|
From: Darjus Loktevic <darjus@gm...> - 2016-08-19 10:16:29
|
Hey Nick, Looks like your socket.send change broke the regregression tests. It seems that something is leaking/isn't being cleaned up as expected if the address is still in use. Would appreciate you taking a look at this. https://circleci.com/gh/jythontools/jython/tree/master Cheers, Darjus |
|
From: Darjus Loktevic <darjus@gm...> - 2016-08-19 02:24:19
|
Agreed, Let's make this change in Jython3. We really cannot break this for Jython2. On Thu, Aug 18, 2016 at 3:49 PM Jeff Allen <ja.py@...> wrote: > I agree with all this. As I said initially: > > It seems clear platform.uname should be consistent with platform.system, > platform.node, and so on. The documentation of platform.system > explicitly mentions 'Java' as an expected return. Not clear that it > should be consistent with os.uname. > > I also agree it is a pain that os.name should not reflect the real "disk > operating system" when so much code uses it like that. I think I saw > that this change has already been made in Jython 3. (Did I dream it?) > > However, I seem to observe (and it may be old code) that os.name gets > used in two ways: in one place to decide what functions might be > available, and in another to decide whether paths like "C:\Users" would > be valid. These uses conflict when you throw in jnr-posix. Perhaps, > against one's initial instincts, the availability of functions in the os > module is best inferred from platform.name rather than os.name. > > Jeff > > Jeff Allen > > On 17/08/2016 17:28, Jim Baker wrote: > > On Wed, Aug 17, 2016 at 9:22 AM, Stefan Richthofer > > <Stefan.Richthofer@... <mailto:Stefan.Richthofer@...>> wrote: > > > > Hey Jeff, > > thanks for your reply! > > > > I agree that in theory, os.uname and platform.uname should be > > consistent. > > And also platform.system with uname. However in practice, IMO it > > would cause much less trouble with not-Jython-aware modules if > > uname would provide native info rather than JVM-info. Jython-aware > > modules can obtain JVM-info from platform.java_ver anyway. On the > > other hand platform.uname always returned JVM-info in Jython until > > now, so there might be Jython-aware code out there relying on this. > > So as a compromise I'd suggest to let platform.uname behave like > > it always used to and os.uname provide native info such that > > non-Jython-aware modules have higher chance to work (especially > > relevant in JyNI; I wouldn't want to monkeypatch this!). os.uname > > should be save for existing Jython-aware modules, since it didn't > > exist at all in Jython prior to 2.7.1. > > > > > > +1, let's make this distinction. Keep os.uname with the new change; > > and make platform.uname go back to being Java information. This is why > > we have the platform module, vs the os module. > > > > I would keep this distinction for Jython 3. > > > > > > (It's already a constant pain that os.name <http://os.name>; is > > 'java' and Alex Grönholm once pointed out in IRC this would switch > > to CPython behavior in Jython 3. IIRC this currently breaks pip in > > Jython on Windows. Maybe this can be fixed with a hack I use in > > JyNI, but that's rather a story for Jython 2.7.2.) > > > > > > Agreed about the constant pain. > > > > If we had the chance to go back in time to fix this for 2.7.0, I would > > have made os.name <http://os.name>; be the underlying OS (eg 'posix' > > instead of 'java'). The os module should be about the underlying OS - > > it mostly is. So definitely we should fix for Jython 3. > > > > > > Summary > > If there are no objections I will make > > - os.uname provide native platform info (for practicability) > > - platform.uname provide JVM-info (for backward-compatibility) > > We still need to more confidently decide how os.uname should > > behave on Windows (however keeping current variant shouldn't be > > too bad I suppose). > > > > > > +1 > > > > Supporting os.uname on Windows make sense. > > > > - Jim > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Jython-dev mailing list > Jython-dev@... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Darjus Loktevic <darjus@gm...> - 2016-08-19 02:21:52
|
Might be useful for us as we have plans for moving away from Ant to Gradle. Also would be useful for Jython users managing Python and Java dependencies together https://engineering.linkedin.com/blog/2016/08/introducing--py-gradle--an-open-source-python-plugin-for-gradle |
|
From: Jeff Allen <ja.py@fa...> - 2016-08-18 05:48:19
|
I agree with all this. As I said initially: It seems clear platform.uname should be consistent with platform.system, platform.node, and so on. The documentation of platform.system explicitly mentions 'Java' as an expected return. Not clear that it should be consistent with os.uname. I also agree it is a pain that os.name should not reflect the real "disk operating system" when so much code uses it like that. I think I saw that this change has already been made in Jython 3. (Did I dream it?) However, I seem to observe (and it may be old code) that os.name gets used in two ways: in one place to decide what functions might be available, and in another to decide whether paths like "C:\Users" would be valid. These uses conflict when you throw in jnr-posix. Perhaps, against one's initial instincts, the availability of functions in the os module is best inferred from platform.name rather than os.name. Jeff Jeff Allen On 17/08/2016 17:28, Jim Baker wrote: > On Wed, Aug 17, 2016 at 9:22 AM, Stefan Richthofer > <Stefan.Richthofer@... <mailto:Stefan.Richthofer@...>> wrote: > > Hey Jeff, > thanks for your reply! > > I agree that in theory, os.uname and platform.uname should be > consistent. > And also platform.system with uname. However in practice, IMO it > would cause much less trouble with not-Jython-aware modules if > uname would provide native info rather than JVM-info. Jython-aware > modules can obtain JVM-info from platform.java_ver anyway. On the > other hand platform.uname always returned JVM-info in Jython until > now, so there might be Jython-aware code out there relying on this. > So as a compromise I'd suggest to let platform.uname behave like > it always used to and os.uname provide native info such that > non-Jython-aware modules have higher chance to work (especially > relevant in JyNI; I wouldn't want to monkeypatch this!). os.uname > should be save for existing Jython-aware modules, since it didn't > exist at all in Jython prior to 2.7.1. > > > +1, let's make this distinction. Keep os.uname with the new change; > and make platform.uname go back to being Java information. This is why > we have the platform module, vs the os module. > > I would keep this distinction for Jython 3. > > > (It's already a constant pain that os.name <http://os.name>; is > 'java' and Alex Grönholm once pointed out in IRC this would switch > to CPython behavior in Jython 3. IIRC this currently breaks pip in > Jython on Windows. Maybe this can be fixed with a hack I use in > JyNI, but that's rather a story for Jython 2.7.2.) > > > Agreed about the constant pain. > > If we had the chance to go back in time to fix this for 2.7.0, I would > have made os.name <http://os.name>; be the underlying OS (eg 'posix' > instead of 'java'). The os module should be about the underlying OS - > it mostly is. So definitely we should fix for Jython 3. > > > Summary > If there are no objections I will make > - os.uname provide native platform info (for practicability) > - platform.uname provide JVM-info (for backward-compatibility) > We still need to more confidently decide how os.uname should > behave on Windows (however keeping current variant shouldn't be > too bad I suppose). > > > +1 > > Supporting os.uname on Windows make sense. > > - Jim > |
|
From: Jim Baker <jim.baker@py...> - 2016-08-17 16:57:12
|
On Wed, Aug 17, 2016 at 9:22 AM, Stefan Richthofer <Stefan.Richthofer@... > wrote: > Hey Jeff, > thanks for your reply! > > I agree that in theory, os.uname and platform.uname should be consistent. > And also platform.system with uname. However in practice, IMO it would > cause much less trouble with not-Jython-aware modules if uname would > provide native info rather than JVM-info. Jython-aware modules can obtain > JVM-info from platform.java_ver anyway. On the other hand platform.uname > always returned JVM-info in Jython until now, so there might be > Jython-aware code out there relying on this. > So as a compromise I'd suggest to let platform.uname behave like it always > used to and os.uname provide native info such that non-Jython-aware modules > have higher chance to work (especially relevant in JyNI; I wouldn't want to > monkeypatch this!). os.uname should be save for existing Jython-aware > modules, since it didn't exist at all in Jython prior to 2.7.1. > +1, let's make this distinction. Keep os.uname with the new change; and make platform.uname go back to being Java information. This is why we have the platform module, vs the os module. I would keep this distinction for Jython 3. > > (It's already a constant pain that os.name is 'java' and Alex Grönholm > once pointed out in IRC this would switch to CPython behavior in Jython 3. > IIRC this currently breaks pip in Jython on Windows. Maybe this can be > fixed with a hack I use in JyNI, but that's rather a story for Jython > 2.7.2.) > Agreed about the constant pain. If we had the chance to go back in time to fix this for 2.7.0, I would have made os.name be the underlying OS (eg 'posix' instead of 'java'). The os module should be about the underlying OS - it mostly is. So definitely we should fix for Jython 3. > > Summary > If there are no objections I will make > - os.uname provide native platform info (for practicability) > - platform.uname provide JVM-info (for backward-compatibility) > We still need to more confidently decide how os.uname should behave on > Windows (however keeping current variant shouldn't be too bad I suppose). > +1 Supporting os.uname on Windows make sense. - Jim |
|
From: Stefan Richthofer <Stefan.R<ichthofer@gm...> - 2016-08-17 15:22:49
|
Hey Jeff,
thanks for your reply!
I agree that in theory, os.uname and platform.uname should be consistent.
And also platform.system with uname. However in practice, IMO it would cause much less trouble with not-Jython-aware modules if uname would provide native info rather than JVM-info. Jython-aware modules can obtain JVM-info from platform.java_ver anyway. On the other hand platform.uname always returned JVM-info in Jython until now, so there might be Jython-aware code out there relying on this.
So as a compromise I'd suggest to let platform.uname behave like it always used to and os.uname provide native info such that non-Jython-aware modules have higher chance to work (especially relevant in JyNI; I wouldn't want to monkeypatch this!). os.uname should be save for existing Jython-aware modules, since it didn't exist at all in Jython prior to 2.7.1.
(It's already a constant pain that os.name is 'java' and Alex Grönholm once pointed out in IRC this would switch to CPython behavior in Jython 3. IIRC this currently breaks pip in Jython on Windows. Maybe this can be fixed with a hack I use in JyNI, but that's rather a story for Jython 2.7.2.)
Summary
If there are no objections I will make
- os.uname provide native platform info (for practicability)
- platform.uname provide JVM-info (for backward-compatibility)
We still need to more confidently decide how os.uname should behave on Windows (however keeping current variant shouldn't be too bad I suppose).
Best
Stefan
> Gesendet: Sonntag, 14. August 2016 um 23:28 Uhr
> Von: "Jeff Allen" <ja.py@...>
> An: jython-dev@...
> Betreff: Re: [Jython-dev] uname
>
> There's an argument that the *platform* of Jython is Java. Sometimes you
> want a clue about how the file system works (e.g. is "C:\" meaningful)
> and sometimes you want to guess what functions are available (as in the
> "Avaliability:" note in the documentation of the os module). It's not
> very clear (I'm looking at the 3.5.2 docs), of the several ways to
> interrogate os or platform, which is to be used as a clue for what purpose.
>
> It seems clear platform.uname should be consistent with platform.system,
> platform.note, and so on. The documentation of platform.system
> explicitly mentions 'Java' as an expected return. Not clear that it
> should be consistent with os.uname.
>
> Jeff Allen
>
> On 14/08/2016 04:26, Stefan Richthofer wrote:
> > Hey all,
> >
> > some months ago I added an implementation of os.uname to posix-module. In a portable fashion and with some extra effort I made this also work on Windows, because I liked the idea of Jython being resilient enough to support this posix-feature no matter if the platform was actually posix or not.
> >
> > Now I became aware of platform.uname, which I think is intended to work in such a portable manner, while os.uname should reflect system's uname in low-level sense. Indeed, also CPython features a Windows-equivalent of uname in platform.uname. Actually their approach wasn't too different to my re-invention of it in Jython's os.uname. With commit 9252c93e85754d6f3056407d3a67ae7633bdf813 I ensured that Jython's os.uname and also platform.uname match CPython's platform.uname on Windows exactly. (Can't use original CPython os.platform implementation, because it uses win32 module.)
> >
> > But...
> > Jython's platform.uname used to report JVM-info:
> > ('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
> > I already broke this behavior by adding os.uname, because inserting JVM-info is only a fallback if os.uname is not available to back os.platform:
> >
> > Jython 2.7.1b3
> > [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
> > Type "help", "copyright", "credits" or "license" for more information.
> >>>> import os, platform
> >>>> os.uname()
> > ('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64')
> >>>> platform.uname()
> > ('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64', '')
> >>>> exit()
> > You can still restore the old behavior by deleting os.uname (must be done before first call to platform.uname because of caching):
> >
> > Jython 2.7.1b3
> > [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
> > Type "help", "copyright", "credits" or "license" for more information.
> >>>> import os, platform
> >>>> del os.uname
> >>>> platform.uname()
> > ('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
> > Now I wonder whether this was the right choice. Also: Maybe Jython should not support os.uname on Windows; e.g. code in platform.py checks platform by looking if os.uname gives an attribute-error.
> > However I'd like to learn about your opinions on this (if you care at all), maybe we could even have a vote.
> > Does someone have or know an actual use-case needing os.platform to provide JVM-info?
> >
> > Current behavior:
> > - Never return JVM-info (is to some extend still available via platform.java_ver())
> > - os.uname and platform.uname behave equal (except that platform.uname appends processor info)
> > - os.uname is also implemented on Windows, equally to platform.uname in common result-elements
> >
> > Note that it is a no-opt to let os.uname provide JVM-info instead of platform-info, because native extensions as supported bY JyNI look at these values to condition on underlying platform (observed in PyOpenGL). This was the original reason why I needed to add os.uname support at all.
> >
> > top 1)
> > Should platform.uname be reverted to provide JVM-info, or should it be kept as it is now?
> >
> > top 2)
> > Should os.uname be workable on Windows?
> > If not, what should it do?
> >
> > a) throw NotImplementedError or return PyNotImplemented
> > (the 'right' way, but not what CPython-code would expect)
> > b) throw AttributeError
> > (satisfying typical checks for am-I-on-Windows/non-posix, unless someone uses hasattr(os, 'uname'))
> > c) Somehow truly remove os.uname on Windows (What would be the best way to achieve this?)
> > (would precisely resemble CPython-behavior, including hasattr(os, 'uname'))
> >
> >
> > Best
> >
> > Stefan
> >
> > ------------------------------------------------------------------------------
> > 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. http://sdm.link/zohodev2dev
> > _______________________________________________
> > Jython-dev mailing list
> > Jython-dev@...
> > https://lists.sourceforge.net/lists/listinfo/jython-dev
> >
>
>
> ------------------------------------------------------------------------------
> 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. http://sdm.link/zohodev2dev
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
|
|
From: Darjus Loktevic <darjus@gm...> - 2016-08-17 02:05:32
|
Hey Guys, Spent some time yesterday and this morning fixing some of the lingering issues with CI and caching bug. With the CI passing, we should strive for an RC release ASAP. https://circleci.com/gh/jythontools/jython Cheers, Darjus |