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: Stefan R. <Ste...@gm...> - 2016-05-15 14:22:44
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div> <div>Hey Jeff,</div> <div> </div> <div>A NIO ByteBuffer being direct makes the difference whether you can access it from native code via JNI:<br/> It provides access to the data in a direct NIO ByteBuffer via a C-style pointer. This means a native library can read or write the very same memory the buffer exposes on Java-side.<br/> So the support for the DIRECT_NIO flag would open up the whole world of JNI/C-use cases for Jython's buffer protocol.</div> <div> </div> <div>See</div> <div> </div> <div>http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#nio_support</div> <div> </div> <div>for official documentation on this feature (i.e. related JNI-API).</div> <div><br/> My concrete use-case is that I can make JyNI put some sugar around this API such that it resembles CPython's buffer protocol, ultimately allowing to hand a Jython-style buffer protocol supporting PyObject from Jython to a CPython-style native C-extension which will recognize it as a CPython-style buffer protocol supporting object.</div> <div><br/> Honestly, direct NIO ByteBuffer is not the only solution to this. JNI can also offer a C-style memory pointer to a byte-array's data (under certain conditions). However this has some drawbacks, but might be suitable as a fallback to some extend.</div> <div> </div> <div>See</div> <div> </div> <div>http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#wp17314<br/> (scroll down to "Get<PrimitiveType>ArrayElements Routines")</div> <div> </div> <div>https://rkennke.wordpress.com/2007/07/28/efficient-jni-programming-iii-array-access</div> <div> </div> <div>Main issue here is that GetByteArrayElements does not guarantee to offer a view onto the data (i.e. if array pinning is not possible for whatever reason), but might only provide a copy. While modified data can be copied back, this would not be sufficient to support CPython's PyObject_GetBuffer method with the PyBUF_WRITABLE flag set.<br/> As a fallback I can (and maybe will) apply a copy-back operation on PyBuffer_Release call. This might work for some extensions, but I suppose the semantics of PyBUF_WRITABLE flag does not intend to have the write-operation only realized not before PyBuffer_Release call (CPython doc does not state this semantics explicitly though).</div> <div> </div> <div>To make the JVM try hard to provide the underlying array without copying I can use GetPrimitiveArrayCritical, but let me cite from its doc:</div> <div> </div> <div>"""<br/> However, there are significant restrictions on how these functions can be used.</div> <div>After calling GetPrimitiveArrayCritical, the native code should not run for an extended period of time before it calls ReleasePrimitiveArrayCritical. We must treat the code inside this pair of functions as running in a "critical region." Inside a critical region, native code must not call other JNI functions, or any system call that may cause the current thread to block and wait for another Java thread. (For example, the current thread must not call read on a stream being written by another Java thread.)</div> <div>These restrictions make it more likely that the native code will obtain an uncopied version of the array, even if the VM does not support pinning. For example, a VM may temporarily disable garbage collection when the native code is holding a pointer to an array obtained via GetPrimitiveArrayCritical.<br/> """</div> <div> </div> <div>Remember that the pointer would be passed to a native C-extension and that the extension's call to PyBuffer_Release would let JyNI trigger ReleasePrimitiveArrayCritical. Do I need to say that we must assume the native extension was designed to work with CPython and doesn't know or care about running in a "critical region" with the implied restrictions? So I think this fallback should only be applied to certain harmless extensions previously checked and white-listed, if at all.</div> <div> </div> <div>As I currently perceive it, direct NIO ByteBuffer is the only save and sufficient way for a full native BufferProtocol support.</div> <div> </div> <div>-Stefan</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> 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> <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> |
|
From: Jeff A. <ja...@fa...> - 2016-05-15 09:57:55
|
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: Jython t. <st...@bu...> - 2016-05-13 16:10:21
|
ACTIVITY SUMMARY (2016-05-06 - 2016-05-13) 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 ( +2) closed 2239 ( +0) total 2519 ( +2) Open issues with patches: 28 Issues opened (2) ================= #2499: Modules should have implicit conversion to string when concate http://bugs.jython.org/issue2499 opened by zyasoft #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 opened by teeohhem 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: Jeff A. <ja...@fa...> - 2016-05-11 18:15:26
|
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: Stefan R. <Ste...@gm...> - 2016-05-11 13:39:00
|
Hey Jeff, > This is working out reasonably well. Sounds like good news! Would you put a draft e.g. on github once it is somehow at a sane state? > 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). > // 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. Maybe JIT applies some magic here, but I would not count on it. However I guess it's presented fairly out of context, so I maybe got the wrong impression. (Which is why I'm looking forward to a complete draft as mentioned above). > 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? Best Stefan > Gesendet: Mittwoch, 11. Mai 2016 um 08:55 Uhr > Von: "Jeff Allen" <ja...@fa...> > An: jyt...@li... > Betreff: Re: [Jython-dev] Jython buffer protocol > > This is working out reasonably well. It results widespread change, but > mostly downwards in complexity. There is less reason to give special > cases a fast path when the underlying storage is indirect. Hopefully > bulk sequential operations on ByteBuffer implementations are well-optimised. > > getByteBuffer(int index), which is actually still getNIOByteBuffer(int > index), does not seem to do as much for me as the Pointer equivalent. I > think requiring a PyBuffer to offer you its index calculation is the way > to go. Something like: > > assert pybuf.getNdim() == 2; > assert pybuf.getShape()[0] == x.length; > > // 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) ); > > > Jeff Allen > > On 07/05/2016 00:50, Jeff Allen wrote: > > 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, > > this may only be a transient arrangement. I don't want to maintain two > > approaches to storage. I favour adding: > > > > ByteBuffer getByteBuffer(); // = getNIOByteBuffer > > ByteBuffer getByteBuffer(int index); > > ByteBuffer getByteBuffer(int... indices); > > > > which differ only in the position() of the returned buffer. Each returns > > a new ByteBuffer, so that clients may call the incremental get and put > > methods without interfering. An alternative is to have only the first, > > but expose the index calculation helpers so one can set the position > > easily in complex cases. > > > > Writing the test code first was quite helpful in this case. > > > > The current getNIOByteBuffer attempts to set the buffer limit according > > to the actual data extent in the view (which is not the whole underlying > > byte array when it's a slice). This seems unnecessary, and is only > > useful in the contiguous case. I figure you should always get the whole > > thing, then work out how many items to read and write from the > > navigation, not from ByteBuffer.remaining(). > > > > Ok, in CPython 2.7 the reference to the underlying object is present in > > the code, just missing from the documentation. I think we can > > accommodate it. > > > > Jeff Allen > > > > On 28/04/2016 11:06, Stefan Richthofer wrote: > >>> this is a breaking change to the API > >> I think this can be achieved without a breaking API-change (detailed comments below). > >> (However if you prefer a slight break to achieve a cleaner API I won't complain.) > >> > >> The possibility that an array-storage access cannot be provided is already contained in the API. > >> If the flag AS_ARRAY is not set, the current API already doesn't guarantee to offer array-access (via PyBuffer.Pointer). > >> > >> Does a type-change of storage field in BaseBuffer count as breaking API change, given that it is > >> protected? Third-parties that extend BaseBuffer might be affected, which can be avoided by > >> option 1), i.e. adding ByteBuffer view as a separate field, e.g. "storageBufferView". > >> We could start with option 1), declare the byte[]-storage field as deprecated and remove it in > >> 2.7.4 or so. This would provide a smooth transition to variant 2). > >> > >> Replacing PyBuffer.Pointer by ByteBuffer would be a breaking change, but could be avoided too. In Java > >> fashion PyBuffer.Pointer and corresponding API/methods can be kept as @deprecated. (Or just kept - > >> I am actually +0 about replacing PyBuffer.Pointer with ByteBuffer) > >> > >> > >>> Concerning the pointer to object member in CPython Py_Buffer, it seems to be a 3.x feature, > >> which may be why I haven't replicated it. > >> > >> Taking another look it seems like this feature was actually backported to Python 2. Py_buffer declaration in > >> object.h of Python 2.7 is titled /* Py3k buffer interface */. However, for sake of compatibility it would > >> be best to support it in Jython, given that it is (presumably) easy to add. > >> > >> > >> Do I miss some aspect? > >> > >> -Stefan > >> > >> > >> Gesendet: Mittwoch, 27. April 2016 um 23:57 Uhr > >> Von: "Jim Baker" <jim...@py...> > >> An: "Jeff Allen" <ja...@fa...> > >> Cc: "Stefan Richthofer" <Ste...@gm...>, "Jython Developers" <jyt...@li...> > >> Betreff: Re: [Jython-dev] Jython buffer protocol > >> > >> On Wed, Apr 27, 2016 at 4:36 PM, Jeff Allen <ja...@fa...> wrote: > >> I'm giving serious consideration to idea 2, that is, the storage implementation is j.n.ByteBuffer, always, and *may* wrap a byte[] object. I'd need to try this out to ensure there is no fatal flaw. > >> *Jim:* this is a breaking change to the API. Do we need to be more careful of possible users? I suspect we are only breaking our own work here: how about you? > >> > >> We should mention such a breaking change. Necessarily we have been very conservative on various aspects of our Java API - there is certainly usage out there. But that has been seen in 2.5 or earlier API definitions. I don't see a problem here - any users will be sophisticated and can readily adapt. > >> > >> We would be saying in this that the Jython PyBuffer is allowed to be less like the CPython one than I've been aiming for. This consistency may be less important than Stefan's use case. The CPython protocol promises efficient access to the storage of an object via a pointer, and we would be saying "only as efficient as a j.n.ByteBuffer" ... although it may turn out there's a backing array. j.n.ByteBuffer does not replace PyBuffer, because it cannot describe strided access or the get-release behaviour. > >> I think this leads to an API in which what I've tried to do with PyBuffer.Pointer we now do by handing out ByteBuffer slices. So Pointer goes away. In that case getBuf() and getNIOByteBuffer() are probably the same thing. I do not think it is safe to hand out the actual storage: it is almost unavoidable clients would manipulate the internal state (position, limit), surprising each other and the PyBuffer implementation if it relies on them, as I think it should. > >> Concerning the pointer to object member in CPython Py_Buffer, it seems to be a 3.x feature, which may be why I haven't replicated it. It seems easy to add. (I'd be rewriting all the constructors anyway.) In CPython it's null when there's a buffer but no object. > >> > >> Jeff Allen > >> > >> On 24/04/2016 15:36, Stefan Richthofer wrote: > >> Jeff, > >> > >> good to hear that you can help with this stuff and also that your answer implies you don't have concerns with the new feature itself. Thinking it through again, I think the following way would be cleanest to add this functionality: > >> > >> Add a ByteBuffer-type storage, either exclusively or in addition to byte[] storage. > >> > >> > >> > >> 1) Version with additional field java.nio.ByteBuffer bufferStorage: > >> > >> Case byte[]-backed PyBuffer: > >> (buffer storage must be view on storage, i.e. backed by it and must always point to first element) > >> > >> storage is byte[] > >> bufferStorage is ByteBuffer.wrap(storage) > >> > >> getNIOByteBuffer() can use bufferStorage and needn't call ByteBuffer.wrap every time again. > >> > >> > >> Case direct ByteBuffer (likely not having backing array): > >> > >> storage is null or if the JVM happens to be capable of providing direct ByteBuffer with byte[] backend: bufferStorage.array() > >> > >> bufferStorage is ByteBuffer.allocateDirect(capacity) > >> > >> Methods that used to access elements of storage directly are enriched by a fallback for case storage == null. The fallback would directly operate on bufferStorage. > >> > >> > >> > >> > >> 2) Version with exclusive Buffer-storage: > >> > >> storage type is java.nioByteBuffer instead of byte[] > >> > >> > >> Case byte[]-backed PyBuffer: > >> > >> storage is ByteBuffer.allocate(capacity) (i.e. non-Direct, so buffer will have backing array!) > >> > >> getNIOByteBuffer() can use storage and needn't call ByteBuffer.wrap. > >> > >> Methods that used to access elements of storage directly now do this on storage.array() rather than on storage itself (should be doable by a simple search/replace refactoring more or less). > >> > >> > >> Case direct ByteBuffer (likely not having backing array): > >> > >> bufferStorage is ByteBuffer.allocateDirect(capacity) > >> > >> Methods that used to access elements of storage directly are enriched by a fallback for case storage.hasArray() == false. The fallback would directly operate on storage's ByteBuffer methods. > >> > >> > >> I can do the work of writing the fallbacks or help with it up to your discretion. > >> > >> > >> Then another thing: I noticed CPython's PyBuffer-pendant contains a reference to the PyObject that exported it, so you can always find the origin of a given PyBuffer. I don't see how this would be feasible with Jython's current PyBuffer implementation. So from JyNI perspective I can store (as a mapping) the exporter in case it is known for some reason, e.g. because PyBuffer was converted from a native CPython-like variant. > >> However there could be situations where the buffer comes from Jython and the origin would be unknown. In that case I would (currently) just provide a NULL-value or PyNone for this field and hope to get away with it for the important extensions. Maybe we could attach a PyBuffer's origin in Jython too...? (e.g. as a JyAttribute only if some global flag is set, which JyNI would then set on load). > >> > >> Best > >> > >> Stefan > >> > >> > >> > >> Gesendet: Samstag, 23. April 2016 um 20:14 Uhr > >> Von: "Jeff Allen" <ja...@fa...> > >> An: "Stefan Richthofer" <Ste...@gm...> > >> Cc: jim...@py... > >> Betreff: Re: [Jython-dev] Jython buffer protocol > >> > >> Hi Stefan. > >> > >> Refreshing my memory about how these classes work, I can see that I took > >> at face value the CPython view that the purpose of the buffer interface > >> is to give clients access to the underlying array of bytes, so > >> abstraction of the storage always gave way to what I thought would be > >> efficient. (Abstraction of the unit to be something other than byte is > >> sketched but clarity and a use case eluded me.) > >> > >> I always feel I've failed if I have to cast. My instinct is for option a. > >> > >> But I think you would not create a "Direct" parallel to BaseBuffer, > >> since it contains a lot of helper methods independent of the storage > >> implementation. Rather, factor it into two layers, the first being > >> either BaseBuffer or AbstractBuffer (depending on what causes least > >> pain) and the next layer being two base classes, one the revised > >> BaseBuffer containing: > >> protected byte[] storage; > >> and the other containing: > >> protected ByteBuffer storage; > >> And in each you migrate case whatever it seems natural should come along > >> with these declarations. > >> > >> I've been meaning to get back to Jython: I could do this groundwork if > >> that would not be confusing. > >> > >> Jeff > >> > >> Jeff Allen > >> > >> On 22/04/2016 21:50, Stefan Richthofer wrote: > >> Hello Jeff, > >> > >> I'm warming up this old thread, because I am about to start actual work on JyNI's support > >> for buffer-protocol / the PyBuffer builtin type. > >> I'd like to point you to my recent pull request https://github.com/jythontools/jython/pull/39[https://github.com/jythontools/jython/pull/39]. > >> It's a preliminary step for adding support for direct java.nio.ByteBuffers. After establishing this flag > >> I am going to add some actual support for it. I see basically two ways to go for this > >> > >> a) Create a parallel class hierarchy to BaseBuffer et al, backed by direct ByteBuffers. E.g. > >> call everything with "Direct": DirectBaseBuffer, DirectSimpleBuffer etc. > >> Then let BufferProtocol implementers check for the flag and use Direct counterpart of the > >> usually used Buffer-Class accordingly. > >> > >> or > >> > >> b) Modify existing BaseBuffer such that storage is Object rather than byte[]. Then according to > >> flags it will be byte[] or ByteBuffer. This variant will involve more explicit type casting than > >> a), but would involve fewer new classes however. > >> > >> What is your opinion about this? > >> > >> Best > >> > >> Stefan > >> > > > > ------------------------------------------------------------------------------ > > Find and fix application performance issues faster with Applications Manager > > Applications Manager provides deep performance insights into multiple tiers of > > your business applications. It resolves application problems quickly and > > reduces your MTTR. Get your free trial! > > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > > _______________________________________________ > > Jython-dev mailing list > > Jyt...@li... > > https://lists.sourceforge.net/lists/listinfo/jython-dev > > > > > ------------------------------------------------------------------------------ > 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: Jeff A. <ja...@fa...> - 2016-05-11 06:56:40
|
This is working out reasonably well. It results widespread change, but
mostly downwards in complexity. There is less reason to give special
cases a fast path when the underlying storage is indirect. Hopefully
bulk sequential operations on ByteBuffer implementations are well-optimised.
getByteBuffer(int index), which is actually still getNIOByteBuffer(int
index), does not seem to do as much for me as the Pointer equivalent. I
think requiring a PyBuffer to offer you its index calculation is the way
to go. Something like:
assert pybuf.getNdim() == 2;
assert pybuf.getShape()[0] == x.length;
// 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) );
Jeff Allen
On 07/05/2016 00:50, Jeff Allen wrote:
> 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,
> this may only be a transient arrangement. I don't want to maintain two
> approaches to storage. I favour adding:
>
> ByteBuffer getByteBuffer(); // = getNIOByteBuffer
> ByteBuffer getByteBuffer(int index);
> ByteBuffer getByteBuffer(int... indices);
>
> which differ only in the position() of the returned buffer. Each returns
> a new ByteBuffer, so that clients may call the incremental get and put
> methods without interfering. An alternative is to have only the first,
> but expose the index calculation helpers so one can set the position
> easily in complex cases.
>
> Writing the test code first was quite helpful in this case.
>
> The current getNIOByteBuffer attempts to set the buffer limit according
> to the actual data extent in the view (which is not the whole underlying
> byte array when it's a slice). This seems unnecessary, and is only
> useful in the contiguous case. I figure you should always get the whole
> thing, then work out how many items to read and write from the
> navigation, not from ByteBuffer.remaining().
>
> Ok, in CPython 2.7 the reference to the underlying object is present in
> the code, just missing from the documentation. I think we can
> accommodate it.
>
> Jeff Allen
>
> On 28/04/2016 11:06, Stefan Richthofer wrote:
>>> this is a breaking change to the API
>> I think this can be achieved without a breaking API-change (detailed comments below).
>> (However if you prefer a slight break to achieve a cleaner API I won't complain.)
>>
>> The possibility that an array-storage access cannot be provided is already contained in the API.
>> If the flag AS_ARRAY is not set, the current API already doesn't guarantee to offer array-access (via PyBuffer.Pointer).
>>
>> Does a type-change of storage field in BaseBuffer count as breaking API change, given that it is
>> protected? Third-parties that extend BaseBuffer might be affected, which can be avoided by
>> option 1), i.e. adding ByteBuffer view as a separate field, e.g. "storageBufferView".
>> We could start with option 1), declare the byte[]-storage field as deprecated and remove it in
>> 2.7.4 or so. This would provide a smooth transition to variant 2).
>>
>> Replacing PyBuffer.Pointer by ByteBuffer would be a breaking change, but could be avoided too. In Java
>> fashion PyBuffer.Pointer and corresponding API/methods can be kept as @deprecated. (Or just kept -
>> I am actually +0 about replacing PyBuffer.Pointer with ByteBuffer)
>>
>>
>>> Concerning the pointer to object member in CPython Py_Buffer, it seems to be a 3.x feature,
>> which may be why I haven't replicated it.
>>
>> Taking another look it seems like this feature was actually backported to Python 2. Py_buffer declaration in
>> object.h of Python 2.7 is titled /* Py3k buffer interface */. However, for sake of compatibility it would
>> be best to support it in Jython, given that it is (presumably) easy to add.
>>
>>
>> Do I miss some aspect?
>>
>> -Stefan
>>
>>
>> Gesendet: Mittwoch, 27. April 2016 um 23:57 Uhr
>> Von: "Jim Baker" <jim...@py...>
>> An: "Jeff Allen" <ja...@fa...>
>> Cc: "Stefan Richthofer" <Ste...@gm...>, "Jython Developers" <jyt...@li...>
>> Betreff: Re: [Jython-dev] Jython buffer protocol
>>
>> On Wed, Apr 27, 2016 at 4:36 PM, Jeff Allen <ja...@fa...> wrote:
>> I'm giving serious consideration to idea 2, that is, the storage implementation is j.n.ByteBuffer, always, and *may* wrap a byte[] object. I'd need to try this out to ensure there is no fatal flaw.
>> *Jim:* this is a breaking change to the API. Do we need to be more careful of possible users? I suspect we are only breaking our own work here: how about you?
>>
>> We should mention such a breaking change. Necessarily we have been very conservative on various aspects of our Java API - there is certainly usage out there. But that has been seen in 2.5 or earlier API definitions. I don't see a problem here - any users will be sophisticated and can readily adapt.
>>
>> We would be saying in this that the Jython PyBuffer is allowed to be less like the CPython one than I've been aiming for. This consistency may be less important than Stefan's use case. The CPython protocol promises efficient access to the storage of an object via a pointer, and we would be saying "only as efficient as a j.n.ByteBuffer" ... although it may turn out there's a backing array. j.n.ByteBuffer does not replace PyBuffer, because it cannot describe strided access or the get-release behaviour.
>> I think this leads to an API in which what I've tried to do with PyBuffer.Pointer we now do by handing out ByteBuffer slices. So Pointer goes away. In that case getBuf() and getNIOByteBuffer() are probably the same thing. I do not think it is safe to hand out the actual storage: it is almost unavoidable clients would manipulate the internal state (position, limit), surprising each other and the PyBuffer implementation if it relies on them, as I think it should.
>> Concerning the pointer to object member in CPython Py_Buffer, it seems to be a 3.x feature, which may be why I haven't replicated it. It seems easy to add. (I'd be rewriting all the constructors anyway.) In CPython it's null when there's a buffer but no object.
>>
>> Jeff Allen
>>
>> On 24/04/2016 15:36, Stefan Richthofer wrote:
>> Jeff,
>>
>> good to hear that you can help with this stuff and also that your answer implies you don't have concerns with the new feature itself. Thinking it through again, I think the following way would be cleanest to add this functionality:
>>
>> Add a ByteBuffer-type storage, either exclusively or in addition to byte[] storage.
>>
>>
>>
>> 1) Version with additional field java.nio.ByteBuffer bufferStorage:
>>
>> Case byte[]-backed PyBuffer:
>> (buffer storage must be view on storage, i.e. backed by it and must always point to first element)
>>
>> storage is byte[]
>> bufferStorage is ByteBuffer.wrap(storage)
>>
>> getNIOByteBuffer() can use bufferStorage and needn't call ByteBuffer.wrap every time again.
>>
>>
>> Case direct ByteBuffer (likely not having backing array):
>>
>> storage is null or if the JVM happens to be capable of providing direct ByteBuffer with byte[] backend: bufferStorage.array()
>>
>> bufferStorage is ByteBuffer.allocateDirect(capacity)
>>
>> Methods that used to access elements of storage directly are enriched by a fallback for case storage == null. The fallback would directly operate on bufferStorage.
>>
>>
>>
>>
>> 2) Version with exclusive Buffer-storage:
>>
>> storage type is java.nioByteBuffer instead of byte[]
>>
>>
>> Case byte[]-backed PyBuffer:
>>
>> storage is ByteBuffer.allocate(capacity) (i.e. non-Direct, so buffer will have backing array!)
>>
>> getNIOByteBuffer() can use storage and needn't call ByteBuffer.wrap.
>>
>> Methods that used to access elements of storage directly now do this on storage.array() rather than on storage itself (should be doable by a simple search/replace refactoring more or less).
>>
>>
>> Case direct ByteBuffer (likely not having backing array):
>>
>> bufferStorage is ByteBuffer.allocateDirect(capacity)
>>
>> Methods that used to access elements of storage directly are enriched by a fallback for case storage.hasArray() == false. The fallback would directly operate on storage's ByteBuffer methods.
>>
>>
>> I can do the work of writing the fallbacks or help with it up to your discretion.
>>
>>
>> Then another thing: I noticed CPython's PyBuffer-pendant contains a reference to the PyObject that exported it, so you can always find the origin of a given PyBuffer. I don't see how this would be feasible with Jython's current PyBuffer implementation. So from JyNI perspective I can store (as a mapping) the exporter in case it is known for some reason, e.g. because PyBuffer was converted from a native CPython-like variant.
>> However there could be situations where the buffer comes from Jython and the origin would be unknown. In that case I would (currently) just provide a NULL-value or PyNone for this field and hope to get away with it for the important extensions. Maybe we could attach a PyBuffer's origin in Jython too...? (e.g. as a JyAttribute only if some global flag is set, which JyNI would then set on load).
>>
>> Best
>>
>> Stefan
>>
>>
>>
>> Gesendet: Samstag, 23. April 2016 um 20:14 Uhr
>> Von: "Jeff Allen" <ja...@fa...>
>> An: "Stefan Richthofer" <Ste...@gm...>
>> Cc: jim...@py...
>> Betreff: Re: [Jython-dev] Jython buffer protocol
>>
>> Hi Stefan.
>>
>> Refreshing my memory about how these classes work, I can see that I took
>> at face value the CPython view that the purpose of the buffer interface
>> is to give clients access to the underlying array of bytes, so
>> abstraction of the storage always gave way to what I thought would be
>> efficient. (Abstraction of the unit to be something other than byte is
>> sketched but clarity and a use case eluded me.)
>>
>> I always feel I've failed if I have to cast. My instinct is for option a.
>>
>> But I think you would not create a "Direct" parallel to BaseBuffer,
>> since it contains a lot of helper methods independent of the storage
>> implementation. Rather, factor it into two layers, the first being
>> either BaseBuffer or AbstractBuffer (depending on what causes least
>> pain) and the next layer being two base classes, one the revised
>> BaseBuffer containing:
>> protected byte[] storage;
>> and the other containing:
>> protected ByteBuffer storage;
>> And in each you migrate case whatever it seems natural should come along
>> with these declarations.
>>
>> I've been meaning to get back to Jython: I could do this groundwork if
>> that would not be confusing.
>>
>> Jeff
>>
>> Jeff Allen
>>
>> On 22/04/2016 21:50, Stefan Richthofer wrote:
>> Hello Jeff,
>>
>> I'm warming up this old thread, because I am about to start actual work on JyNI's support
>> for buffer-protocol / the PyBuffer builtin type.
>> I'd like to point you to my recent pull request https://github.com/jythontools/jython/pull/39[https://github.com/jythontools/jython/pull/39].
>> It's a preliminary step for adding support for direct java.nio.ByteBuffers. After establishing this flag
>> I am going to add some actual support for it. I see basically two ways to go for this
>>
>> a) Create a parallel class hierarchy to BaseBuffer et al, backed by direct ByteBuffers. E.g.
>> call everything with "Direct": DirectBaseBuffer, DirectSimpleBuffer etc.
>> Then let BufferProtocol implementers check for the flag and use Direct counterpart of the
>> usually used Buffer-Class accordingly.
>>
>> or
>>
>> b) Modify existing BaseBuffer such that storage is Object rather than byte[]. Then according to
>> flags it will be byte[] or ByteBuffer. This variant will involve more explicit type casting than
>> a), but would involve fewer new classes however.
>>
>> What is your opinion about this?
>>
>> Best
>>
>> Stefan
>>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
|
|
From: Jeff A. <ja...@fa...> - 2016-05-06 23:51:01
|
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, this may only be a transient arrangement. I don't want to maintain two approaches to storage. I favour adding: ByteBuffer getByteBuffer(); // = getNIOByteBuffer ByteBuffer getByteBuffer(int index); ByteBuffer getByteBuffer(int... indices); which differ only in the position() of the returned buffer. Each returns a new ByteBuffer, so that clients may call the incremental get and put methods without interfering. An alternative is to have only the first, but expose the index calculation helpers so one can set the position easily in complex cases. Writing the test code first was quite helpful in this case. The current getNIOByteBuffer attempts to set the buffer limit according to the actual data extent in the view (which is not the whole underlying byte array when it's a slice). This seems unnecessary, and is only useful in the contiguous case. I figure you should always get the whole thing, then work out how many items to read and write from the navigation, not from ByteBuffer.remaining(). Ok, in CPython 2.7 the reference to the underlying object is present in the code, just missing from the documentation. I think we can accommodate it. Jeff Allen On 28/04/2016 11:06, Stefan Richthofer wrote: >> this is a breaking change to the API > I think this can be achieved without a breaking API-change (detailed comments below). > (However if you prefer a slight break to achieve a cleaner API I won't complain.) > > The possibility that an array-storage access cannot be provided is already contained in the API. > If the flag AS_ARRAY is not set, the current API already doesn't guarantee to offer array-access (via PyBuffer.Pointer). > > Does a type-change of storage field in BaseBuffer count as breaking API change, given that it is > protected? Third-parties that extend BaseBuffer might be affected, which can be avoided by > option 1), i.e. adding ByteBuffer view as a separate field, e.g. "storageBufferView". > We could start with option 1), declare the byte[]-storage field as deprecated and remove it in > 2.7.4 or so. This would provide a smooth transition to variant 2). > > Replacing PyBuffer.Pointer by ByteBuffer would be a breaking change, but could be avoided too. In Java > fashion PyBuffer.Pointer and corresponding API/methods can be kept as @deprecated. (Or just kept - > I am actually +0 about replacing PyBuffer.Pointer with ByteBuffer) > > >> Concerning the pointer to object member in CPython Py_Buffer, it seems to be a 3.x feature, > which may be why I haven't replicated it. > > Taking another look it seems like this feature was actually backported to Python 2. Py_buffer declaration in > object.h of Python 2.7 is titled /* Py3k buffer interface */. However, for sake of compatibility it would > be best to support it in Jython, given that it is (presumably) easy to add. > > > Do I miss some aspect? > > -Stefan > > > Gesendet: Mittwoch, 27. April 2016 um 23:57 Uhr > Von: "Jim Baker" <jim...@py...> > An: "Jeff Allen" <ja...@fa...> > Cc: "Stefan Richthofer" <Ste...@gm...>, "Jython Developers" <jyt...@li...> > Betreff: Re: [Jython-dev] Jython buffer protocol > > On Wed, Apr 27, 2016 at 4:36 PM, Jeff Allen <ja...@fa...> wrote: > I'm giving serious consideration to idea 2, that is, the storage implementation is j.n.ByteBuffer, always, and *may* wrap a byte[] object. I'd need to try this out to ensure there is no fatal flaw. > *Jim:* this is a breaking change to the API. Do we need to be more careful of possible users? I suspect we are only breaking our own work here: how about you? > > We should mention such a breaking change. Necessarily we have been very conservative on various aspects of our Java API - there is certainly usage out there. But that has been seen in 2.5 or earlier API definitions. I don't see a problem here - any users will be sophisticated and can readily adapt. > > We would be saying in this that the Jython PyBuffer is allowed to be less like the CPython one than I've been aiming for. This consistency may be less important than Stefan's use case. The CPython protocol promises efficient access to the storage of an object via a pointer, and we would be saying "only as efficient as a j.n.ByteBuffer" ... although it may turn out there's a backing array. j.n.ByteBuffer does not replace PyBuffer, because it cannot describe strided access or the get-release behaviour. > I think this leads to an API in which what I've tried to do with PyBuffer.Pointer we now do by handing out ByteBuffer slices. So Pointer goes away. In that case getBuf() and getNIOByteBuffer() are probably the same thing. I do not think it is safe to hand out the actual storage: it is almost unavoidable clients would manipulate the internal state (position, limit), surprising each other and the PyBuffer implementation if it relies on them, as I think it should. > Concerning the pointer to object member in CPython Py_Buffer, it seems to be a 3.x feature, which may be why I haven't replicated it. It seems easy to add. (I'd be rewriting all the constructors anyway.) In CPython it's null when there's a buffer but no object. > > Jeff Allen > > On 24/04/2016 15:36, Stefan Richthofer wrote: > Jeff, > > good to hear that you can help with this stuff and also that your answer implies you don't have concerns with the new feature itself. Thinking it through again, I think the following way would be cleanest to add this functionality: > > Add a ByteBuffer-type storage, either exclusively or in addition to byte[] storage. > > > > 1) Version with additional field java.nio.ByteBuffer bufferStorage: > > Case byte[]-backed PyBuffer: > (buffer storage must be view on storage, i.e. backed by it and must always point to first element) > > storage is byte[] > bufferStorage is ByteBuffer.wrap(storage) > > getNIOByteBuffer() can use bufferStorage and needn't call ByteBuffer.wrap every time again. > > > Case direct ByteBuffer (likely not having backing array): > > storage is null or if the JVM happens to be capable of providing direct ByteBuffer with byte[] backend: bufferStorage.array() > > bufferStorage is ByteBuffer.allocateDirect(capacity) > > Methods that used to access elements of storage directly are enriched by a fallback for case storage == null. The fallback would directly operate on bufferStorage. > > > > > 2) Version with exclusive Buffer-storage: > > storage type is java.nioByteBuffer instead of byte[] > > > Case byte[]-backed PyBuffer: > > storage is ByteBuffer.allocate(capacity) (i.e. non-Direct, so buffer will have backing array!) > > getNIOByteBuffer() can use storage and needn't call ByteBuffer.wrap. > > Methods that used to access elements of storage directly now do this on storage.array() rather than on storage itself (should be doable by a simple search/replace refactoring more or less). > > > Case direct ByteBuffer (likely not having backing array): > > bufferStorage is ByteBuffer.allocateDirect(capacity) > > Methods that used to access elements of storage directly are enriched by a fallback for case storage.hasArray() == false. The fallback would directly operate on storage's ByteBuffer methods. > > > I can do the work of writing the fallbacks or help with it up to your discretion. > > > Then another thing: I noticed CPython's PyBuffer-pendant contains a reference to the PyObject that exported it, so you can always find the origin of a given PyBuffer. I don't see how this would be feasible with Jython's current PyBuffer implementation. So from JyNI perspective I can store (as a mapping) the exporter in case it is known for some reason, e.g. because PyBuffer was converted from a native CPython-like variant. > However there could be situations where the buffer comes from Jython and the origin would be unknown. In that case I would (currently) just provide a NULL-value or PyNone for this field and hope to get away with it for the important extensions. Maybe we could attach a PyBuffer's origin in Jython too...? (e.g. as a JyAttribute only if some global flag is set, which JyNI would then set on load). > > Best > > Stefan > > > > Gesendet: Samstag, 23. April 2016 um 20:14 Uhr > Von: "Jeff Allen" <ja...@fa...> > An: "Stefan Richthofer" <Ste...@gm...> > Cc: jim...@py... > Betreff: Re: [Jython-dev] Jython buffer protocol > > Hi Stefan. > > Refreshing my memory about how these classes work, I can see that I took > at face value the CPython view that the purpose of the buffer interface > is to give clients access to the underlying array of bytes, so > abstraction of the storage always gave way to what I thought would be > efficient. (Abstraction of the unit to be something other than byte is > sketched but clarity and a use case eluded me.) > > I always feel I've failed if I have to cast. My instinct is for option a. > > But I think you would not create a "Direct" parallel to BaseBuffer, > since it contains a lot of helper methods independent of the storage > implementation. Rather, factor it into two layers, the first being > either BaseBuffer or AbstractBuffer (depending on what causes least > pain) and the next layer being two base classes, one the revised > BaseBuffer containing: > protected byte[] storage; > and the other containing: > protected ByteBuffer storage; > And in each you migrate case whatever it seems natural should come along > with these declarations. > > I've been meaning to get back to Jython: I could do this groundwork if > that would not be confusing. > > Jeff > > Jeff Allen > > On 22/04/2016 21:50, Stefan Richthofer wrote: > Hello Jeff, > > I'm warming up this old thread, because I am about to start actual work on JyNI's support > for buffer-protocol / the PyBuffer builtin type. > I'd like to point you to my recent pull request https://github.com/jythontools/jython/pull/39[https://github.com/jythontools/jython/pull/39]. > It's a preliminary step for adding support for direct java.nio.ByteBuffers. After establishing this flag > I am going to add some actual support for it. I see basically two ways to go for this > > a) Create a parallel class hierarchy to BaseBuffer et al, backed by direct ByteBuffers. E.g. > call everything with "Direct": DirectBaseBuffer, DirectSimpleBuffer etc. > Then let BufferProtocol implementers check for the flag and use Direct counterpart of the > usually used Buffer-Class accordingly. > > or > > b) Modify existing BaseBuffer such that storage is Object rather than byte[]. Then according to > flags it will be byte[] or ByteBuffer. This variant will involve more explicit type casting than > a), but would involve fewer new classes however. > > What is your opinion about this? > > Best > > Stefan > |
|
From: Jython t. <st...@bu...> - 2016-05-06 16:10:21
|
ACTIVITY SUMMARY (2016-04-29 - 2016-05-06) 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 278 ( +3) closed 2239 ( +0) total 2517 ( +3) Open issues with patches: 28 Issues opened (3) ================= #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 opened by nbertram #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 opened by amylin1 #2498: Jython 2.7.0 jump command is not working http://bugs.jython.org/issue2498 opened by snargul Most recent 15 issues with no replies (15) ========================================== #2498: Jython 2.7.0 jump command is not working http://bugs.jython.org/issue2498 #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: Darjus L. <da...@gm...> - 2016-05-01 23:47:53
|
Hey Stefan,
That's great diligence. The changes look safe to me.
Cheers,
Darjus
On Sun, May 1, 2016 at 12:51 PM Stefan Richthofer <Ste...@gm...>
wrote:
> Jim, thanks for your kind reply.
>
> >we generally follow a commit-then-review (CTR) process
> Alright. I was aware of this workflow implicitly so far. For #36 and #38 I
> was just looking for an explicit 'okay' even for save stuff, because it's
> in the hot shortly-before-release-phase (and it had been postulated that
> new features should go into 2.7.2, which was stated assuming less delay for
> 2.7.1 I suppose).
>
>
> *Gesendet:* Sonntag, 01. Mai 2016 um 03:40 Uhr
> *Von:* "Jim Baker" <jim...@py...>
> *An:* "Stefan Richthofer" <Ste...@gm...>
> *Cc:* "Jython Developers" <jyt...@li...>
> *Betreff:* Re: [Jython-dev] Pull requests #36 and #38
> On Sat, Apr 30, 2016 at 5:34 AM, Stefan Richthofer <
> Ste...@gm...> wrote:
>>
>> Hello everybody,
>>
>> given that Jython 2.7.1 was delayed so long (actually we're about to
>> reach the planned release date for 2.7.2)
>
>
> Yes, I'm really well aware of how much we have slipped. On the other hand,
> this past week I had a chance to see a demo of some soon to be production
> code using our latest work, running on Twisted with SSL connections and
> against Java and Clojure libraries, all with quite reasonable performance
> due to no GIL.
>
> So at this time, I'm hoping that we can complete by PyCon; or at least the
> PyCon sprints for those attending. See bit.ly/jython-triage-2_7_1 for
> outstanding bugs. Bugs of urgent/immediate severity block the release
> candidate; but we should include with respect to the high bugs as well, all
> of which have outstanding fixes to be applied.
>
> The real challenge is the immediate bug ("the publication bug" for
> class/type mappings in http://bugs.jython.org/issue2487); it's something
> Darjus Loktevic and I have put in some time into, but so far, not resolved.
> But the final exam in the course I'm teaching is this Monday; and I just
> got back from the OpenStack Summit where I was kicking off a new project.
> So I personally have some time to squash that bug coming up real soon now.
>
>
>> I'd like to merge the pull requests
>>
>> https://github.com/jythontools/jython/pull/36
>>
>> https://github.com/jythontools/jython/pull/38
>>
>> before the release. I think there is no risk to introduce new issues with
>> these changes, because they really do simple stuff or just add a function.
>
>
> +1. For committers, we generally follow a commit-then-review (CTR)
> process. The other committers haven't had a chance to review these PRs in
> advance - certainly not me - but in general - simple stuff/adds a function
> has worked safely for us with CTR. Basically any committer should know when
> to reach out to another one for review of the tricky bits - that's why we
> were so designated :)
>
> See my separate email sent on this same thread on how we actually merge
> such PRs. (tl;dr it's manual.)
>
>
>>
>> Regarding #36:
>> Given that there was no uname in Jython before there cannot be (sane*)
>> code that could be affected even if my implementation was faulty.
>>
>> * code might be conditioned on uname not existing, but I regard it a
>> no-goal to preserve bug-compatibility to old versions
>>
>>
>> Regarding #38:
>> Changes only concern if-branches that don't apply to Jython anyway.
>> Actually these branches could have been removed completely (stuff that is
>> conditioned onto e.g. os.name == 'nt'). I did not remove them because
>> Jython code might want to hack around with them, e.g. by actively setting
>> os.name to some value != 'java' (code I doubt to exist anyway). However
>> for JyNI I need these branches additionally secured by a check for !=
>> 'java' for reasons that go too far to explain here (I can give details on
>> the use case on demand).
>> So semantically these checks don't change anything for Jython at all;
>> they even reduce the number of failing checks a bit, as os.name !=
>> 'java' usually wraps an entire block of several checks for various
>> platforms not applying to Jython-case.
>>
>> If there are no concerns I would check these into Jython someday next
>> week. Presumably these commits would allow me to drop the JyNI-specific
>> ctypes python code and use the CPython-bundled ctypes entirely. #36 is also
>> required for JyOpenGL.
>>
>> Regards
>>
>> Stefan
>>
>>
>> ------------------------------------------------------------------------------
>> Find and fix application performance issues faster with Applications
>> Manager
>> Applications Manager provides deep performance insights into multiple
>> tiers of
>> your business applications. It resolves application problems quickly and
>> reduces your MTTR. Get your free trial!
>> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
>> _______________________________________________
>> Jython-dev mailing list
>> Jyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager Applications Manager provides deep performance insights into
> multiple tiers of your business applications. It resolves application
> problems quickly and reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________
> Jython-dev mailing list Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
|
|
From: Stefan R. <Ste...@gm...> - 2016-05-01 02:50:18
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>Jim, thanks for your kind reply.</div> <div> </div> <div>>we generally follow a commit-then-review (CTR) process</div> <div>Alright. I was aware of this workflow implicitly so far. For #36 and #38 I was just looking for an explicit 'okay' even for save stuff, because it's in the hot shortly-before-release-phase (and it had been postulated that new features should go into 2.7.2, which was stated assuming less delay for 2.7.1 I suppose).</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, 01. Mai 2016 um 03:40 Uhr<br/> <b>Von:</b> "Jim Baker" <jim...@py...><br/> <b>An:</b> "Stefan Richthofer" <Ste...@gm...><br/> <b>Cc:</b> "Jython Developers" <jyt...@li...><br/> <b>Betreff:</b> Re: [Jython-dev] Pull requests #36 and #38</div> <div name="quoted-content"> <div> <div class="gmail_extra"> <div class="gmail_quote">On Sat, Apr 30, 2016 at 5:34 AM, Stefan Richthofer <span><<a href="Ste...@gm..." target="_parent">Ste...@gm...</a>></span> wrote: <blockquote class="gmail_quote" style="margin: 0.0px 0.0px 0.0px 0.8ex;border-left-width: 1.0px;border-left-style: solid;border-left-color: rgb(204,204,204);padding-left: 1.0ex;">Hello everybody,<br/> <br/> given that Jython 2.7.1 was delayed so long (actually we're about to reach the planned release date for 2.7.2)</blockquote> <div> </div> <div>Yes, I'm really well aware of how much we have slipped. On the other hand, this past week I had a chance to see a demo of some soon to be production code using our latest work, running on Twisted with SSL connections and against Java and Clojure libraries, all with quite reasonable performance due to no GIL.</div> <div> </div> <div>So at this time, I'm hoping that we can complete by PyCon; or at least the PyCon sprints for those attending. See <a href="http://bit.ly/jython-triage-2_7_1" target="_blank">bit.ly/jython-triage-2_7_1</a> for outstanding bugs. Bugs of urgent/immediate severity block the release candidate; but we should include with respect to the high bugs as well, all of which have outstanding fixes to be applied.</div> <div> </div> <div>The real challenge is the immediate bug ("the publication bug" for class/type mappings in <a href="http://bugs.jython.org/issue2487" target="_blank">http://bugs.jython.org/issue2487</a>); it's something Darjus Loktevic and I have put in some time into, but so far, not resolved. But the final exam in the course I'm teaching is this Monday; and I just got back from the OpenStack Summit where I was kicking off a new project. So I personally have some time to squash that bug coming up real soon now.</div> <div> </div> <blockquote class="gmail_quote" style="margin: 0.0px 0.0px 0.0px 0.8ex;border-left-width: 1.0px;border-left-style: solid;border-left-color: rgb(204,204,204);padding-left: 1.0ex;">I'd like to merge the pull requests<br/> <br/> <a href="https://github.com/jythontools/jython/pull/36" target="_blank">https://github.com/jythontools/jython/pull/36</a><br/> <br/> <a href="https://github.com/jythontools/jython/pull/38" target="_blank">https://github.com/jythontools/jython/pull/38</a><br/> <br/> before the release. I think there is no risk to introduce new issues with these changes, because they really do simple stuff or just add a function.</blockquote> <div> </div> <div>+1. For committers, we generally follow a commit-then-review (CTR) process. The other committers haven't had a chance to review these PRs in advance - certainly not me - but in general - simple stuff/adds a function has worked safely for us with CTR. Basically any committer should know when to reach out to another one for review of the tricky bits - that's why we were so designated :)</div> <div> </div> <div>See my separate email sent on this same thread on how we actually merge such PRs. (tl;dr it's manual.)</div> <div> </div> <blockquote class="gmail_quote" style="margin: 0.0px 0.0px 0.0px 0.8ex;border-left-width: 1.0px;border-left-style: solid;border-left-color: rgb(204,204,204);padding-left: 1.0ex;"><br/> Regarding #36:<br/> Given that there was no uname in Jython before there cannot be (sane*) code that could be affected even if my implementation was faulty.<br/> <br/> * code might be conditioned on uname not existing, but I regard it a no-goal to preserve bug-compatibility to old versions<br/> <br/> <br/> Regarding #38:<br/> Changes only concern if-branches that don't apply to Jython anyway. Actually these branches could have been removed completely (stuff that is conditioned onto e.g. <a href="http://os.name" target="_blank">os.name</a> == 'nt'). I did not remove them because Jython code might want to hack around with them, e.g. by actively setting <a href="http://os.name" target="_blank">os.name</a> to some value != 'java' (code I doubt to exist anyway). However for JyNI I need these branches additionally secured by a check for != 'java' for reasons that go too far to explain here (I can give details on the use case on demand).<br/> So semantically these checks don't change anything for Jython at all; they even reduce the number of failing checks a bit, as <a href="http://os.name" target="_blank">os.name</a> != 'java' usually wraps an entire block of several checks for various platforms not applying to Jython-case.<br/> <br/> If there are no concerns I would check these into Jython someday next week. Presumably these commits would allow me to drop the JyNI-specific ctypes python code and use the CPython-bundled ctypes entirely. #36 is also required for JyOpenGL.<br/> <br/> Regards<br/> <br/> Stefan<br/> <br/> ------------------------------------------------------------------------------<br/> Find and fix application performance issues faster with Applications Manager<br/> Applications Manager provides deep performance insights into multiple tiers of<br/> your business applications. It resolves application problems quickly and<br/> reduces your MTTR. Get your free trial!<br/> <a href="https://ad.doubleclick.net/ddm/clk/302982198;130105516;z" target="_blank">https://ad.doubleclick.net/ddm/clk/302982198;130105516;z</a><br/> _______________________________________________<br/> Jython-dev mailing list<br/> <a href="Jyt...@li..." target="_parent">Jyt...@li...</a><br/> <a href="https://lists.sourceforge.net/lists/listinfo/jython-dev" target="_blank">https://lists.sourceforge.net/lists/listinfo/jython-dev</a></blockquote> </div> </div> </div> ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! <a href="https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________" target="_blank">https://ad.doubleclick.net/ddm/clk/302982198;130105516;z_______________________________________________</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></body></html> |
|
From: Jim B. <jim...@py...> - 2016-05-01 01:41:17
|
On Sat, Apr 30, 2016 at 5:34 AM, Stefan Richthofer <Ste...@gm...
> wrote:
> Hello everybody,
>
> given that Jython 2.7.1 was delayed so long (actually we're about to reach
> the planned release date for 2.7.2)
Yes, I'm really well aware of how much we have slipped. On the other hand,
this past week I had a chance to see a demo of some soon to be production
code using our latest work, running on Twisted with SSL connections and
against Java and Clojure libraries, all with quite reasonable performance
due to no GIL.
So at this time, I'm hoping that we can complete by PyCon; or at least the
PyCon sprints for those attending. See bit.ly/jython-triage-2_7_1 for
outstanding bugs. Bugs of urgent/immediate severity block the release
candidate; but we should include with respect to the high bugs as well, all
of which have outstanding fixes to be applied.
The real challenge is the immediate bug ("the publication bug" for
class/type mappings in http://bugs.jython.org/issue2487); it's something
Darjus Loktevic and I have put in some time into, but so far, not resolved.
But the final exam in the course I'm teaching is this Monday; and I just
got back from the OpenStack Summit where I was kicking off a new project.
So I personally have some time to squash that bug coming up real soon now.
> I'd like to merge the pull requests
>
> https://github.com/jythontools/jython/pull/36
>
> https://github.com/jythontools/jython/pull/38
>
> before the release. I think there is no risk to introduce new issues with
> these changes, because they really do simple stuff or just add a function.
>
+1. For committers, we generally follow a commit-then-review (CTR) process.
The other committers haven't had a chance to review these PRs in advance -
certainly not me - but in general - simple stuff/adds a function has
worked safely for us with CTR. Basically any committer should know when to
reach out to another one for review of the tricky bits - that's why we were
so designated :)
See my separate email sent on this same thread on how we actually merge
such PRs. (tl;dr it's manual.)
>
> Regarding #36:
> Given that there was no uname in Jython before there cannot be (sane*)
> code that could be affected even if my implementation was faulty.
>
> * code might be conditioned on uname not existing, but I regard it a
> no-goal to preserve bug-compatibility to old versions
>
>
> Regarding #38:
> Changes only concern if-branches that don't apply to Jython anyway.
> Actually these branches could have been removed completely (stuff that is
> conditioned onto e.g. os.name == 'nt'). I did not remove them because
> Jython code might want to hack around with them, e.g. by actively setting
> os.name to some value != 'java' (code I doubt to exist anyway). However
> for JyNI I need these branches additionally secured by a check for !=
> 'java' for reasons that go too far to explain here (I can give details on
> the use case on demand).
> So semantically these checks don't change anything for Jython at all; they
> even reduce the number of failing checks a bit, as os.name != 'java'
> usually wraps an entire block of several checks for various platforms not
> applying to Jython-case.
>
> If there are no concerns I would check these into Jython someday next
> week. Presumably these commits would allow me to drop the JyNI-specific
> ctypes python code and use the CPython-bundled ctypes entirely. #36 is also
> required for JyOpenGL.
>
> Regards
>
> Stefan
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
|
|
From: Jim B. <jim...@py...> - 2016-05-01 00:58:45
|
On Sat, Apr 30, 2016 at 6:25 AM, Jeff Allen <ja...@fa...> wrote: > I don't have any rights to this account. I see we invite pull requests > there: out of curiosity, is there a bridge back to hg? > We are just using GitHub PRs as a convenient place to review patches. Any commits against hg.python.org/jython occur via a manual commit. We will be using https://github.com/jython/ for 2.7.2 and get off of hg. To do so, we first want to modernize our build process to use Maven dependencies (via Gradle); and filter out the extlib jars from the repo (so no more included binaries). I like the way GitHub gives us a build server (but not the way it's > always red). > Darjus Loktevic set this up this CI earlier this year, and it has been very convenient in finding bugs for us to fix ;) such as the deadlock, now publication bug that has been blocking 2.7.1 ( http://bugs.jython.org/issue2487) I especially like how CircleCI works as a JVM with the turbo button (https://en.wikipedia.org/wiki/Turbo_button) turned off - very handy for finding bugs due to timing races. - Jim |
|
From: Jeff A. <ja...@fa...> - 2016-04-30 12:26:14
|
I don't have any rights to this account. I see we invite pull requests there: out of curiosity, is there a bridge back to hg? I like the way GitHub gives us a build server (but not the way it's always red). J Jeff Allen On 30/04/2016 12:34, Stefan Richthofer wrote: > Hello everybody, > > given that Jython 2.7.1 was delayed so long (actually we're about to reach the planned release date for 2.7.2) I'd like to merge the pull requests > > https://github.com/jythontools/jython/pull/36 > > https://github.com/jythontools/jython/pull/38 > > before the release. I think there is no risk to introduce new issues with these changes, because they really do simple stuff or just add a function. > > Regarding #36: > Given that there was no uname in Jython before there cannot be (sane*) code that could be affected even if my implementation was faulty. > > * code might be conditioned on uname not existing, but I regard it a no-goal to preserve bug-compatibility to old versions > > > Regarding #38: > Changes only concern if-branches that don't apply to Jython anyway. Actually these branches could have been removed completely (stuff that is conditioned onto e.g. os.name == 'nt'). I did not remove them because Jython code might want to hack around with them, e.g. by actively setting os.name to some value != 'java' (code I doubt to exist anyway). However for JyNI I need these branches additionally secured by a check for != 'java' for reasons that go too far to explain here (I can give details on the use case on demand). > So semantically these checks don't change anything for Jython at all; they even reduce the number of failing checks a bit, as os.name != 'java' usually wraps an entire block of several checks for various platforms not applying to Jython-case. > > If there are no concerns I would check these into Jython someday next week. Presumably these commits would allow me to drop the JyNI-specific ctypes python code and use the CPython-bundled ctypes entirely. #36 is also required for JyOpenGL. > > Regards > > Stefan > > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Stefan R. <Ste...@gm...> - 2016-04-30 11:34:56
|
Hello everybody, given that Jython 2.7.1 was delayed so long (actually we're about to reach the planned release date for 2.7.2) I'd like to merge the pull requests https://github.com/jythontools/jython/pull/36 https://github.com/jythontools/jython/pull/38 before the release. I think there is no risk to introduce new issues with these changes, because they really do simple stuff or just add a function. Regarding #36: Given that there was no uname in Jython before there cannot be (sane*) code that could be affected even if my implementation was faulty. * code might be conditioned on uname not existing, but I regard it a no-goal to preserve bug-compatibility to old versions Regarding #38: Changes only concern if-branches that don't apply to Jython anyway. Actually these branches could have been removed completely (stuff that is conditioned onto e.g. os.name == 'nt'). I did not remove them because Jython code might want to hack around with them, e.g. by actively setting os.name to some value != 'java' (code I doubt to exist anyway). However for JyNI I need these branches additionally secured by a check for != 'java' for reasons that go too far to explain here (I can give details on the use case on demand). So semantically these checks don't change anything for Jython at all; they even reduce the number of failing checks a bit, as os.name != 'java' usually wraps an entire block of several checks for various platforms not applying to Jython-case. If there are no concerns I would check these into Jython someday next week. Presumably these commits would allow me to drop the JyNI-specific ctypes python code and use the CPython-bundled ctypes entirely. #36 is also required for JyOpenGL. Regards Stefan |
|
From: Jython t. <st...@bu...> - 2016-04-29 16:10:22
|
ACTIVITY SUMMARY (2016-04-22 - 2016-04-29) Jython tracker at http://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 275 ( -1) closed 2239 ( +1) total 2514 ( +0) Open issues with patches: 28 Most recent 15 issues with no replies (15) ========================================== #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 #2318: test_zipimport_jy failure on Windows http://bugs.jython.org/issue2318 #2317: test_urllib2 failure on Windows http://bugs.jython.org/issue2317 #2316: test_tarfile file-mode failures on Windows http://bugs.jython.org/issue2316 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) ================================ #2495: Tomcat webapp classloader leak when using jython-standalone http://bugs.jython.org/issue2495 6 msgs Issues closed (1) ================= #2493: Reply Back. http://bugs.jython.org/issue2493 closed by amak |
|
From: Rory O'D. <ror...@or...> - 2016-04-29 12:55:22
|
Hi Alan, Early Access b116 <https://jdk9.java.net/download/> for JDK 9 is available on java.net, summary of changes are listed here <http://download.java.net/java/jdk9/changes/jdk-9+116.html>. Early Access b115 <https://jdk9.java.net/jigsaw/> (#4909) for JDK 9 with Project Jigsaw is available on java.net. Recent changes: * in b114 o Replace –com.apple.eawt –com.apple.eio With platform independent alternatives in java.awt * in b115 o As per JEP 260, all non-Critical types/members should be moved out of sun/reflect and placed into a non-exported package. Only critical APIs should remain in sun.reflect. We are very interested in hearing your experiences in testing any Early Access builds. Have you have begun testing against JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered showstopper issues that you would like to discuss? We would really like to hear your findings so far, either reply to me or via the mailing lists [1], [2]. Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/ [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland |
|
From: Stefan R. <Ste...@gm...> - 2016-04-28 10:06:31
|
>this is a breaking change to the API
I think this can be achieved without a breaking API-change (detailed comments below).
(However if you prefer a slight break to achieve a cleaner API I won't complain.)
The possibility that an array-storage access cannot be provided is already contained in the API.
If the flag AS_ARRAY is not set, the current API already doesn't guarantee to offer array-access (via PyBuffer.Pointer).
Does a type-change of storage field in BaseBuffer count as breaking API change, given that it is
protected? Third-parties that extend BaseBuffer might be affected, which can be avoided by
option 1), i.e. adding ByteBuffer view as a separate field, e.g. "storageBufferView".
We could start with option 1), declare the byte[]-storage field as deprecated and remove it in
2.7.4 or so. This would provide a smooth transition to variant 2).
Replacing PyBuffer.Pointer by ByteBuffer would be a breaking change, but could be avoided too. In Java
fashion PyBuffer.Pointer and corresponding API/methods can be kept as @deprecated. (Or just kept -
I am actually +0 about replacing PyBuffer.Pointer with ByteBuffer)
> Concerning the pointer to object member in CPython Py_Buffer, it seems to be a 3.x feature,
which may be why I haven't replicated it.
Taking another look it seems like this feature was actually backported to Python 2. Py_buffer declaration in
object.h of Python 2.7 is titled /* Py3k buffer interface */. However, for sake of compatibility it would
be best to support it in Jython, given that it is (presumably) easy to add.
Do I miss some aspect?
-Stefan
Gesendet: Mittwoch, 27. April 2016 um 23:57 Uhr
Von: "Jim Baker" <jim...@py...>
An: "Jeff Allen" <ja...@fa...>
Cc: "Stefan Richthofer" <Ste...@gm...>, "Jython Developers" <jyt...@li...>
Betreff: Re: [Jython-dev] Jython buffer protocol
On Wed, Apr 27, 2016 at 4:36 PM, Jeff Allen <ja...@fa...> wrote:
I'm giving serious consideration to idea 2, that is, the storage implementation is j.n.ByteBuffer, always, and *may* wrap a byte[] object. I'd need to try this out to ensure there is no fatal flaw.
*Jim:* this is a breaking change to the API. Do we need to be more careful of possible users? I suspect we are only breaking our own work here: how about you?
We should mention such a breaking change. Necessarily we have been very conservative on various aspects of our Java API - there is certainly usage out there. But that has been seen in 2.5 or earlier API definitions. I don't see a problem here - any users will be sophisticated and can readily adapt.
We would be saying in this that the Jython PyBuffer is allowed to be less like the CPython one than I've been aiming for. This consistency may be less important than Stefan's use case. The CPython protocol promises efficient access to the storage of an object via a pointer, and we would be saying "only as efficient as a j.n.ByteBuffer" ... although it may turn out there's a backing array. j.n.ByteBuffer does not replace PyBuffer, because it cannot describe strided access or the get-release behaviour.
I think this leads to an API in which what I've tried to do with PyBuffer.Pointer we now do by handing out ByteBuffer slices. So Pointer goes away. In that case getBuf() and getNIOByteBuffer() are probably the same thing. I do not think it is safe to hand out the actual storage: it is almost unavoidable clients would manipulate the internal state (position, limit), surprising each other and the PyBuffer implementation if it relies on them, as I think it should.
Concerning the pointer to object member in CPython Py_Buffer, it seems to be a 3.x feature, which may be why I haven't replicated it. It seems easy to add. (I'd be rewriting all the constructors anyway.) In CPython it's null when there's a buffer but no object.
Jeff Allen
On 24/04/2016 15:36, Stefan Richthofer wrote:
Jeff,
good to hear that you can help with this stuff and also that your answer implies you don't have concerns with the new feature itself. Thinking it through again, I think the following way would be cleanest to add this functionality:
Add a ByteBuffer-type storage, either exclusively or in addition to byte[] storage.
1) Version with additional field java.nio.ByteBuffer bufferStorage:
Case byte[]-backed PyBuffer:
(buffer storage must be view on storage, i.e. backed by it and must always point to first element)
storage is byte[]
bufferStorage is ByteBuffer.wrap(storage)
getNIOByteBuffer() can use bufferStorage and needn't call ByteBuffer.wrap every time again.
Case direct ByteBuffer (likely not having backing array):
storage is null or if the JVM happens to be capable of providing direct ByteBuffer with byte[] backend: bufferStorage.array()
bufferStorage is ByteBuffer.allocateDirect(capacity)
Methods that used to access elements of storage directly are enriched by a fallback for case storage == null. The fallback would directly operate on bufferStorage.
2) Version with exclusive Buffer-storage:
storage type is java.nioByteBuffer instead of byte[]
Case byte[]-backed PyBuffer:
storage is ByteBuffer.allocate(capacity) (i.e. non-Direct, so buffer will have backing array!)
getNIOByteBuffer() can use storage and needn't call ByteBuffer.wrap.
Methods that used to access elements of storage directly now do this on storage.array() rather than on storage itself (should be doable by a simple search/replace refactoring more or less).
Case direct ByteBuffer (likely not having backing array):
bufferStorage is ByteBuffer.allocateDirect(capacity)
Methods that used to access elements of storage directly are enriched by a fallback for case storage.hasArray() == false. The fallback would directly operate on storage's ByteBuffer methods.
I can do the work of writing the fallbacks or help with it up to your discretion.
Then another thing: I noticed CPython's PyBuffer-pendant contains a reference to the PyObject that exported it, so you can always find the origin of a given PyBuffer. I don't see how this would be feasible with Jython's current PyBuffer implementation. So from JyNI perspective I can store (as a mapping) the exporter in case it is known for some reason, e.g. because PyBuffer was converted from a native CPython-like variant.
However there could be situations where the buffer comes from Jython and the origin would be unknown. In that case I would (currently) just provide a NULL-value or PyNone for this field and hope to get away with it for the important extensions. Maybe we could attach a PyBuffer's origin in Jython too...? (e.g. as a JyAttribute only if some global flag is set, which JyNI would then set on load).
Best
Stefan
Gesendet: Samstag, 23. April 2016 um 20:14 Uhr
Von: "Jeff Allen" <ja...@fa...>
An: "Stefan Richthofer" <Ste...@gm...>
Cc: jim...@py...
Betreff: Re: [Jython-dev] Jython buffer protocol
Hi Stefan.
Refreshing my memory about how these classes work, I can see that I took
at face value the CPython view that the purpose of the buffer interface
is to give clients access to the underlying array of bytes, so
abstraction of the storage always gave way to what I thought would be
efficient. (Abstraction of the unit to be something other than byte is
sketched but clarity and a use case eluded me.)
I always feel I've failed if I have to cast. My instinct is for option a.
But I think you would not create a "Direct" parallel to BaseBuffer,
since it contains a lot of helper methods independent of the storage
implementation. Rather, factor it into two layers, the first being
either BaseBuffer or AbstractBuffer (depending on what causes least
pain) and the next layer being two base classes, one the revised
BaseBuffer containing:
protected byte[] storage;
and the other containing:
protected ByteBuffer storage;
And in each you migrate case whatever it seems natural should come along
with these declarations.
I've been meaning to get back to Jython: I could do this groundwork if
that would not be confusing.
Jeff
Jeff Allen
On 22/04/2016 21:50, Stefan Richthofer wrote:
Hello Jeff,
I'm warming up this old thread, because I am about to start actual work on JyNI's support
for buffer-protocol / the PyBuffer builtin type.
I'd like to point you to my recent pull request https://github.com/jythontools/jython/pull/39[https://github.com/jythontools/jython/pull/39].
It's a preliminary step for adding support for direct java.nio.ByteBuffers. After establishing this flag
I am going to add some actual support for it. I see basically two ways to go for this
a) Create a parallel class hierarchy to BaseBuffer et al, backed by direct ByteBuffers. E.g.
call everything with "Direct": DirectBaseBuffer, DirectSimpleBuffer etc.
Then let BufferProtocol implementers check for the flag and use Direct counterpart of the
usually used Buffer-Class accordingly.
or
b) Modify existing BaseBuffer such that storage is Object rather than byte[]. Then according to
flags it will be byte[] or ByteBuffer. This variant will involve more explicit type casting than
a), but would involve fewer new classes however.
What is your opinion about this?
Best
Stefan
Gesendet: Donnerstag, 07. August 2014 um 21:49 Uhr
Von: "Jeff Allen" <ja...@fa...>
An: "Stefan Richthofer" <Ste...@gm...>
Cc: "Jython Developers" <jyt...@li...>
Betreff: Re: [Jython-dev] Jython buffer protocol
Jeff Allen
On 06/08/2014 02:28, Stefan Richthofer wrote:
Jeff,
I just quickly scanned the changes and everything looks fine as far as I see. PyByteArray and BaseBytes may need adjustments too (on this occasion remember to add resizeCheck() in irepeat).
Thanks for looking that over. I was rather asking whether the use case
was served adequately by the addition of PyBUF.AS_ARRAY, hasArray() and
getNIOByteBuffer(), since you obviously have a clear idea of it.
I took a second/third look but didn't find anything to change in
BaseBytes and PyByteArray: when arguments objects have the Buffer API
they are accessed through the abstract API (not as byte[]). PyByteArray
obviously can support AS_ARRAY, and that seems to be covered in
SimpleBuffer.
I fixed the irepeat bug in the previous change set: it's a distinct
issue, so it gets its own change set. Thanks for spotting.
I know there would be careful thinking needed on how to design such intermediate layer and it would be a drastic change of the current API. I just wanted to make you aware of this idea. Maybe one could approach this in Jython 3 or so, or work out a minimal implementation of it, being open for more advanced use in the future.
I think it would make sense to have a layer below BaseBytes that
contained all those mechanisms that work without assuming a byte[]
storage. This would help you implement PyBuffer in an object unable to
export a byte[]. That wouldn't change the API and is likely harmless to
efficiency. But more radical ideas, I agree, need more careful thought.
(The present design has had a lot of thought.)
Jeff
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk[http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk]
_______________________________________________
Jython-dev mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/jython-dev
|
|
From: Jim B. <jim...@py...> - 2016-04-27 22:30:00
|
On Wed, Apr 27, 2016 at 4:36 PM, Jeff Allen <ja...@fa...> wrote: > I'm giving serious consideration to idea 2, that is, the storage > implementation is j.n.ByteBuffer, always, and *may* wrap a byte[] object. > I'd need to try this out to ensure there is no fatal flaw. > > *Jim:* this is a breaking change to the API. Do we need to be more careful > of possible users? I suspect we are only breaking our own work here: how > about you? > We should mention such a breaking change. Necessarily we have been very conservative on various aspects of our Java API - there is certainly usage out there. But that has been seen in 2.5 or earlier API definitions. I don't see a problem here - any users will be sophisticated and can readily adapt. > We would be saying in this that the Jython PyBuffer is allowed to be less > like the CPython one than I've been aiming for. This consistency may be > less important than Stefan's use case. The CPython protocol promises > efficient access to the storage of an object via a pointer, and we would be > saying "only as efficient as a j.n.ByteBuffer" ... although it may turn out > there's a backing array. j.n.ByteBuffer does not replace PyBuffer, because > it cannot describe strided access or the get-release behaviour. > > I think this leads to an API in which what I've tried to do with > PyBuffer.Pointer we now do by handing out ByteBuffer slices. So Pointer > goes away. In that case getBuf() and getNIOByteBuffer() are probably the > same thing. I do not think it is safe to hand out the actual storage: it is > almost unavoidable clients would manipulate the internal state (position, > limit), surprising each other and the PyBuffer implementation if it relies > on them, as I think it should. > > Concerning the pointer to object member in CPython Py_Buffer, it seems to > be a 3.x feature, which may be why I haven't replicated it. It seems easy > to add. (I'd be rewriting all the constructors anyway.) In CPython it's > null when there's a buffer but no object. > > Jeff Allen > > On 24/04/2016 15:36, Stefan Richthofer wrote: > > Jeff, > > good to hear that you can help with this stuff and also that your answer implies you don't have concerns with the new feature itself. Thinking it through again, I think the following way would be cleanest to add this functionality: > > Add a ByteBuffer-type storage, either exclusively or in addition to byte[] storage. > > > > 1) Version with additional field java.nio.ByteBuffer bufferStorage: > > Case byte[]-backed PyBuffer: > (buffer storage must be view on storage, i.e. backed by it and must always point to first element) > > storage is byte[] > bufferStorage is ByteBuffer.wrap(storage) > > getNIOByteBuffer() can use bufferStorage and needn't call ByteBuffer.wrap every time again. > > > Case direct ByteBuffer (likely not having backing array): > > storage is null or if the JVM happens to be capable of providing direct ByteBuffer with byte[] backend: bufferStorage.array() > > bufferStorage is ByteBuffer.allocateDirect(capacity) > > Methods that used to access elements of storage directly are enriched by a fallback for case storage == null. The fallback would directly operate on bufferStorage. > > > > > 2) Version with exclusive Buffer-storage: > > storage type is java.nioByteBuffer instead of byte[] > > > Case byte[]-backed PyBuffer: > > storage is ByteBuffer.allocate(capacity) (i.e. non-Direct, so buffer will have backing array!) > > getNIOByteBuffer() can use storage and needn't call ByteBuffer.wrap. > > Methods that used to access elements of storage directly now do this on storage.array() rather than on storage itself (should be doable by a simple search/replace refactoring more or less). > > > Case direct ByteBuffer (likely not having backing array): > > bufferStorage is ByteBuffer.allocateDirect(capacity) > > Methods that used to access elements of storage directly are enriched by a fallback for case storage.hasArray() == false. The fallback would directly operate on storage's ByteBuffer methods. > > > I can do the work of writing the fallbacks or help with it up to your discretion. > > > Then another thing: I noticed CPython's PyBuffer-pendant contains a reference to the PyObject that exported it, so you can always find the origin of a given PyBuffer. I don't see how this would be feasible with Jython's current PyBuffer implementation. So from JyNI perspective I can store (as a mapping) the exporter in case it is known for some reason, e.g. because PyBuffer was converted from a native CPython-like variant. > However there could be situations where the buffer comes from Jython and the origin would be unknown. In that case I would (currently) just provide a NULL-value or PyNone for this field and hope to get away with it for the important extensions. Maybe we could attach a PyBuffer's origin in Jython too...? (e.g. as a JyAttribute only if some global flag is set, which JyNI would then set on load). > > Best > > Stefan > > > > > Gesendet: Samstag, 23. April 2016 um 20:14 Uhr > Von: "Jeff Allen" <ja...@fa...> <ja...@fa...> > An: "Stefan Richthofer" <Ste...@gm...> <Ste...@gm...> > Cc: jim...@py... > Betreff: Re: [Jython-dev] Jython buffer protocol > > Hi Stefan. > > Refreshing my memory about how these classes work, I can see that I took > at face value the CPython view that the purpose of the buffer interface > is to give clients access to the underlying array of bytes, so > abstraction of the storage always gave way to what I thought would be > efficient. (Abstraction of the unit to be something other than byte is > sketched but clarity and a use case eluded me.) > > I always feel I've failed if I have to cast. My instinct is for option a. > > But I think you would not create a "Direct" parallel to BaseBuffer, > since it contains a lot of helper methods independent of the storage > implementation. Rather, factor it into two layers, the first being > either BaseBuffer or AbstractBuffer (depending on what causes least > pain) and the next layer being two base classes, one the revised > BaseBuffer containing: > protected byte[] storage; > and the other containing: > protected ByteBuffer storage; > And in each you migrate case whatever it seems natural should come along > with these declarations. > > I've been meaning to get back to Jython: I could do this groundwork if > that would not be confusing. > > Jeff > > Jeff Allen > > On 22/04/2016 21:50, Stefan Richthofer wrote: > > Hello Jeff, > > I'm warming up this old thread, because I am about to start actual work on JyNI's support > for buffer-protocol / the PyBuffer builtin type. > I'd like to point you to my recent pull request https://github.com/jythontools/jython/pull/39. > It's a preliminary step for adding support for direct java.nio.ByteBuffers. After establishing this flag > I am going to add some actual support for it. I see basically two ways to go for this > > a) Create a parallel class hierarchy to BaseBuffer et al, backed by direct ByteBuffers. E.g. > call everything with "Direct": DirectBaseBuffer, DirectSimpleBuffer etc. > Then let BufferProtocol implementers check for the flag and use Direct counterpart of the > usually used Buffer-Class accordingly. > > or > > b) Modify existing BaseBuffer such that storage is Object rather than byte[]. Then according to > flags it will be byte[] or ByteBuffer. This variant will involve more explicit type casting than > a), but would involve fewer new classes however. > > What is your opinion about this? > > Best > > Stefan > > > > Gesendet: Donnerstag, 07. August 2014 um 21:49 Uhr > Von: "Jeff Allen" <ja...@fa...> <ja...@fa...> > An: "Stefan Richthofer" <Ste...@gm...> <Ste...@gm...> > Cc: "Jython Developers" <jyt...@li...> <jyt...@li...> > Betreff: Re: [Jython-dev] Jython buffer protocol > > > Jeff Allen > > On 06/08/2014 02:28, Stefan Richthofer wrote: > > Jeff, > > I just quickly scanned the changes and everything looks fine as far as I see. PyByteArray and BaseBytes may need adjustments too (on this occasion remember to add resizeCheck() in irepeat). > > Thanks for looking that over. I was rather asking whether the use case > was served adequately by the addition of PyBUF.AS_ARRAY, hasArray() and > getNIOByteBuffer(), since you obviously have a clear idea of it. > > I took a second/third look but didn't find anything to change in > BaseBytes and PyByteArray: when arguments objects have the Buffer API > they are accessed through the abstract API (not as byte[]). PyByteArray > obviously can support AS_ARRAY, and that seems to be covered in > SimpleBuffer. > > I fixed the irepeat bug in the previous change set: it's a distinct > issue, so it gets its own change set. Thanks for spotting. > > I know there would be careful thinking needed on how to design such intermediate layer and it would be a drastic change of the current API. I just wanted to make you aware of this idea. Maybe one could approach this in Jython 3 or so, or work out a minimal implementation of it, being open for more advanced use in the future. > > > I think it would make sense to have a layer below BaseBytes that > contained all those mechanisms that work without assuming a byte[] > storage. This would help you implement PyBuffer in an object unable to > export a byte[]. That wouldn't change the API and is likely harmless to > efficiency. But more radical ideas, I agree, need more careful thought. > (The present design has had a lot of thought.) > > Jeff > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future.http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Jython-dev mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/jython-dev > > > |
|
From: Jeff A. <ja...@fa...> - 2016-04-27 21:51:04
|
I'm giving serious consideration to idea 2, that is, the storage implementation is j.n.ByteBuffer, always, and *may* wrap a byte[] object. I'd need to try this out to ensure there is no fatal flaw. *Jim:* this is a breaking change to the API. Do we need to be more careful of possible users? I suspect we are only breaking our own work here: how about you? We would be saying in this that the Jython PyBuffer is allowed to be less like the CPython one than I've been aiming for. This consistency may be less important than Stefan's use case. The CPython protocol promises efficient access to the storage of an object via a pointer, and we would be saying "only as efficient as a j.n.ByteBuffer" ... although it may turn out there's a backing array. j.n.ByteBuffer does not replace PyBuffer, because it cannot describe strided access or the get-release behaviour. I think this leads to an API in which what I've tried to do with PyBuffer.Pointer we now do by handing out ByteBuffer slices. So Pointer goes away. In that case getBuf() and getNIOByteBuffer() are probably the same thing. I do not think it is safe to hand out the actual storage: it is almost unavoidable clients would manipulate the internal state (position, limit), surprising each other and the PyBuffer implementation if it relies on them, as I think it should. Concerning the pointer to object member in CPython Py_Buffer, it seems to be a 3.x feature, which may be why I haven't replicated it. It seems easy to add. (I'd be rewriting all the constructors anyway.) In CPython it's null when there's a buffer but no object. Jeff Allen On 24/04/2016 15:36, Stefan Richthofer wrote: > Jeff, > > good to hear that you can help with this stuff and also that your answer implies you don't have concerns with the new feature itself. Thinking it through again, I think the following way would be cleanest to add this functionality: > > Add a ByteBuffer-type storage, either exclusively or in addition to byte[] storage. > > > > 1) Version with additional field java.nio.ByteBuffer bufferStorage: > > Case byte[]-backed PyBuffer: > (buffer storage must be view on storage, i.e. backed by it and must always point to first element) > > storage is byte[] > bufferStorage is ByteBuffer.wrap(storage) > > getNIOByteBuffer() can use bufferStorage and needn't call ByteBuffer.wrap every time again. > > > Case direct ByteBuffer (likely not having backing array): > > storage is null or if the JVM happens to be capable of providing direct ByteBuffer with byte[] backend: bufferStorage.array() > > bufferStorage is ByteBuffer.allocateDirect(capacity) > > Methods that used to access elements of storage directly are enriched by a fallback for case storage == null. The fallback would directly operate on bufferStorage. > > > > > 2) Version with exclusive Buffer-storage: > > storage type is java.nioByteBuffer instead of byte[] > > > Case byte[]-backed PyBuffer: > > storage is ByteBuffer.allocate(capacity) (i.e. non-Direct, so buffer will have backing array!) > > getNIOByteBuffer() can use storage and needn't call ByteBuffer.wrap. > > Methods that used to access elements of storage directly now do this on storage.array() rather than on storage itself (should be doable by a simple search/replace refactoring more or less). > > > Case direct ByteBuffer (likely not having backing array): > > bufferStorage is ByteBuffer.allocateDirect(capacity) > > Methods that used to access elements of storage directly are enriched by a fallback for case storage.hasArray() == false. The fallback would directly operate on storage's ByteBuffer methods. > > > I can do the work of writing the fallbacks or help with it up to your discretion. > > > Then another thing: I noticed CPython's PyBuffer-pendant contains a reference to the PyObject that exported it, so you can always find the origin of a given PyBuffer. I don't see how this would be feasible with Jython's current PyBuffer implementation. So from JyNI perspective I can store (as a mapping) the exporter in case it is known for some reason, e.g. because PyBuffer was converted from a native CPython-like variant. > However there could be situations where the buffer comes from Jython and the origin would be unknown. In that case I would (currently) just provide a NULL-value or PyNone for this field and hope to get away with it for the important extensions. Maybe we could attach a PyBuffer's origin in Jython too...? (e.g. as a JyAttribute only if some global flag is set, which JyNI would then set on load). > > Best > > Stefan > > > >> Gesendet: Samstag, 23. April 2016 um 20:14 Uhr >> Von: "Jeff Allen" <ja...@fa...> >> An: "Stefan Richthofer" <Ste...@gm...> >> Cc: jim...@py... >> Betreff: Re: [Jython-dev] Jython buffer protocol >> >> Hi Stefan. >> >> Refreshing my memory about how these classes work, I can see that I took >> at face value the CPython view that the purpose of the buffer interface >> is to give clients access to the underlying array of bytes, so >> abstraction of the storage always gave way to what I thought would be >> efficient. (Abstraction of the unit to be something other than byte is >> sketched but clarity and a use case eluded me.) >> >> I always feel I've failed if I have to cast. My instinct is for option a. >> >> But I think you would not create a "Direct" parallel to BaseBuffer, >> since it contains a lot of helper methods independent of the storage >> implementation. Rather, factor it into two layers, the first being >> either BaseBuffer or AbstractBuffer (depending on what causes least >> pain) and the next layer being two base classes, one the revised >> BaseBuffer containing: >> protected byte[] storage; >> and the other containing: >> protected ByteBuffer storage; >> And in each you migrate case whatever it seems natural should come along >> with these declarations. >> >> I've been meaning to get back to Jython: I could do this groundwork if >> that would not be confusing. >> >> Jeff >> >> Jeff Allen >> >> On 22/04/2016 21:50, Stefan Richthofer wrote: >>> Hello Jeff, >>> >>> I'm warming up this old thread, because I am about to start actual work on JyNI's support >>> for buffer-protocol / the PyBuffer builtin type. >>> I'd like to point you to my recent pull request https://github.com/jythontools/jython/pull/39. >>> It's a preliminary step for adding support for direct java.nio.ByteBuffers. After establishing this flag >>> I am going to add some actual support for it. I see basically two ways to go for this >>> >>> a) Create a parallel class hierarchy to BaseBuffer et al, backed by direct ByteBuffers. E.g. >>> call everything with "Direct": DirectBaseBuffer, DirectSimpleBuffer etc. >>> Then let BufferProtocol implementers check for the flag and use Direct counterpart of the >>> usually used Buffer-Class accordingly. >>> >>> or >>> >>> b) Modify existing BaseBuffer such that storage is Object rather than byte[]. Then according to >>> flags it will be byte[] or ByteBuffer. This variant will involve more explicit type casting than >>> a), but would involve fewer new classes however. >>> >>> What is your opinion about this? >>> >>> Best >>> >>> Stefan >>> >>> >>>> Gesendet: Donnerstag, 07. August 2014 um 21:49 Uhr >>>> Von: "Jeff Allen" <ja...@fa...> >>>> An: "Stefan Richthofer" <Ste...@gm...> >>>> Cc: "Jython Developers" <jyt...@li...> >>>> Betreff: Re: [Jython-dev] Jython buffer protocol >>>> >>>> >>>> Jeff Allen >>>> >>>> On 06/08/2014 02:28, Stefan Richthofer wrote: >>>>> Jeff, >>>>> >>>>> I just quickly scanned the changes and everything looks fine as far as I see. PyByteArray and BaseBytes may need adjustments too (on this occasion remember to add resizeCheck() in irepeat). >>>> Thanks for looking that over. I was rather asking whether the use case >>>> was served adequately by the addition of PyBUF.AS_ARRAY, hasArray() and >>>> getNIOByteBuffer(), since you obviously have a clear idea of it. >>>> >>>> I took a second/third look but didn't find anything to change in >>>> BaseBytes and PyByteArray: when arguments objects have the Buffer API >>>> they are accessed through the abstract API (not as byte[]). PyByteArray >>>> obviously can support AS_ARRAY, and that seems to be covered in >>>> SimpleBuffer. >>>> >>>> I fixed the irepeat bug in the previous change set: it's a distinct >>>> issue, so it gets its own change set. Thanks for spotting. >>>>> I know there would be careful thinking needed on how to design such intermediate layer and it would be a drastic change of the current API. I just wanted to make you aware of this idea. Maybe one could approach this in Jython 3 or so, or work out a minimal implementation of it, being open for more advanced use in the future. >>>>> >>>> I think it would make sense to have a layer below BaseBytes that >>>> contained all those mechanisms that work without assuming a byte[] >>>> storage. This would help you implement PyBuffer in an object unable to >>>> export a byte[]. That wouldn't change the API and is likely harmless to >>>> efficiency. But more radical ideas, I agree, need more careful thought. >>>> (The present design has had a lot of thought.) >>>> >>>> Jeff >>>> >>>> ------------------------------------------------------------------------------ >>>> Infragistics Professional >>>> Build stunning WinForms apps today! >>>> Reboot your WinForms applications with our WinForms controls. >>>> Build a bridge from your legacy apps to the future. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Jython-dev mailing list >>>> Jyt...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jython-dev >>>> >> |
|
From: Isaiah P. <is...@gm...> - 2016-04-24 20:06:06
|
Hi Frank, I've just signed the contributor agreement (my username on bugs.python.org is isaiah), thanks for pointing it out. Because of the current immature status of the branch, I am trying to get as much working as possible, so I didn't run the tests nor add new tests for my work, hope that makes sense for the moment. I also encountered a problem when trying to add the `int.from_bytes` class method, >>> int.from_bytes(b'\xfc\x00', byteorder='big', signed=True) -1024 I tried to add ```java @ExposedClassMethod(doc = BuiltinDocs.int_from_bytes_doc) final static PyObject long_from_bytes(PyType type, PyObject[] args, String[] keywords) { ... } ``` But get the following exception when compiling: */home/isaiah/codes/java/jython3/build.xml:799: java.lang.NoSuchMethodError: org.python.core.PyBuiltinClassMethodNarrow: method <init>(Ljava/lang/String;)V not found at org.python.core.PyLong$long_from_bytes_exposer.<init>(Unknown Source) at org.python.core.PyLong$PyExposer.<init>(Unknown Source) at org.python.core.PyLong.<clinit>(PyLong.java) at org.python.core.Py.newLong(Py.java:617) at org.python.core.FloatInfo.getInfo(PySystemState.java:1943) at org.python.core.PySystemState.<clinit>(PySystemState.java:195) at org.python.util.JycompileAntTask.process(JycompileAntTask.java:30) at org.python.util.GlobMatchingTask.execute(GlobMatchingTask.java:70) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:435) at org.apache.tools.ant.Target.performTasks(Target.java:456) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1405) at org.apache.tools.ant.Project.executeTarget(Project.java:1376) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1260) at org.apache.tools.ant.Main.runBuild(Main.java:853) at org.apache.tools.ant.Main.startAnt(Main.java:235) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:285) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:112) * It works with the following method, but it won't support keyword parameters, and the `signed` argument cannot be optional: ```java final static PyObject long_from_bytes(PyType type, PyObject bytes, PyObject byteorder, PyObject signed) { ``` How to express such method signature in native implemented method? Regards, Isaiah On Sun, 24 Apr 2016 at 19:42 fwi...@gm... <fwi...@gm...> wrote: > On Thu, Apr 21, 2016 at 5:56 AM, Isaiah Peng <is...@gm...> wrote: > > Hi guys, > > > > I am working on python 3 support for jython, in the jython/jython3 > > repository, I've created a few pull request on github, > > > > https://github.com/jython/jython3/pulls > > > > Please don't hesitate to give your valuable feedbacks. > Hi Isaiah, > > I am planning to start really examining these today, thanks for the > pull requests! I'm especially excited to see that you have not only > managed to somehow work with the very immature jython3 work, but also > updated Jython's grammar: few dare to venture there :). > > Have you signed a Python contributor agreement? For a set of > contributions of this size we'll need that (or at least assurance that > you plan to do that as soon as possible). > > The directions are here: > > http://python.org/psf/contrib/ > > Note that it requires a username from bugs.python.org with a (p)ython, > not the one you might have at bugs.jython.org. Don't worry about the > Jython-specific one, it was for past contributors, only worry about > this one: > > http://www.python.org/psf/contrib/contrib-form/ > > -Frank > |
|
From: <fwi...@gm...> - 2016-04-24 17:42:36
|
On Thu, Apr 21, 2016 at 5:56 AM, Isaiah Peng <is...@gm...> wrote: > Hi guys, > > I am working on python 3 support for jython, in the jython/jython3 > repository, I've created a few pull request on github, > > https://github.com/jython/jython3/pulls > > Please don't hesitate to give your valuable feedbacks. Hi Isaiah, I am planning to start really examining these today, thanks for the pull requests! I'm especially excited to see that you have not only managed to somehow work with the very immature jython3 work, but also updated Jython's grammar: few dare to venture there :). Have you signed a Python contributor agreement? For a set of contributions of this size we'll need that (or at least assurance that you plan to do that as soon as possible). The directions are here: http://python.org/psf/contrib/ Note that it requires a username from bugs.python.org with a (p)ython, not the one you might have at bugs.jython.org. Don't worry about the Jython-specific one, it was for past contributors, only worry about this one: http://www.python.org/psf/contrib/contrib-form/ -Frank |
|
From: Jython t. <st...@bu...> - 2016-04-22 16:10:22
|
ACTIVITY SUMMARY (2016-04-15 - 2016-04-22) Jython tracker at http://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 276 ( +3) closed 2238 ( +0) total 2514 ( +3) Open issues with patches: 28 Issues opened (3) ================= #2493: Reply Back. http://bugs.jython.org/issue2493 opened by nobody #2494: Support for pydoc_data http://bugs.jython.org/issue2494 opened by jenselme #2495: Tomcat webapp classloader leak when using jython-standalone http://bugs.jython.org/issue2495 opened by cbr...@pi... Most recent 15 issues with no replies (15) ========================================== #2495: Tomcat webapp classloader leak when using jython-standalone http://bugs.jython.org/issue2495 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2493: Reply Back. http://bugs.jython.org/issue2493 #2492: NPE for PythonInterpreter after new PyInteger http://bugs.jython.org/issue2492 #2490: Using Jython together with Adafruit_DHT python library http://bugs.jython.org/issue2490 #2486: SSL illegal-state exception in jsonrpc http://bugs.jython.org/issue2486 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2483: Serialized form incompatibility of PyObject between versions 2 http://bugs.jython.org/issue2483 #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: Isaiah P. <is...@gm...> - 2016-04-21 12:57:07
|
Hi guys, I am working on python 3 support for jython, in the jython/jython3 repository, I've created a few pull request on github, https://github.com/jython/jython3/pulls Please don't hesitate to give your valuable feedbacks. Thanks, Isaiah |
|
From: Jython t. <st...@bu...> - 2016-04-15 16:10:21
|
ACTIVITY SUMMARY (2016-04-08 - 2016-04-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 273 ( +3) closed 2238 ( +0) total 2511 ( +3) Open issues with patches: 28 Issues opened (3) ================= #2490: Using Jython together with Adafruit_DHT python library http://bugs.jython.org/issue2490 opened by Topkek #2491: a security issue in jython http://bugs.jython.org/issue2491 opened by redrain #2492: NPE for PythonInterpreter after new PyInteger http://bugs.jython.org/issue2492 opened by flungo Most recent 15 issues with no replies (15) ========================================== #2492: NPE for PythonInterpreter after new PyInteger http://bugs.jython.org/issue2492 #2490: Using Jython together with Adafruit_DHT python library http://bugs.jython.org/issue2490 #2486: SSL illegal-state exception in jsonrpc http://bugs.jython.org/issue2486 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2483: Serialized form incompatibility of PyObject between versions 2 http://bugs.jython.org/issue2483 #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-04-15 08:23:09
|
Hi Alan, Early Access b113 <https://jdk9.java.net/download/> for JDK 9 is available on java.net, summary of changes are listed here <http://download.java.net/java/jdk9/changes/jdk-9+113.html>. Early Access b113 <https://jdk9.java.net/jigsaw/> (#4664) for JDK 9 with Project Jigsaw is available on java.net. * The important change in this build is that root modules when compiling code in the unnamed module, or when running and the main class is loaded from the class path, do not include the EE modules. More on this in JEP 261. * The other change in this build is that the -Xpatch option is now aligned with what we have documented in JEP 261, support for the old form has been removed. We are very interested in hearing your experiences in testing any Early Access builds. Have you have begun testing against JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered showstopper issues that you would like to discuss? We would really like to hear your findings so far, either reply to me or via the mailing lists [1], [2]. Rgds,Rory [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/ [2] http://mail.openjdk.java.net/pipermail/jdk9-dev/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin,Ireland |
101 messages has been excluded from this view by a project administrator.
