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: Jim B. <jim...@py...> - 2016-08-24 19:29:28
|
Jeff, I think the change looks good other than one small nit - the following new files use Windows-style line endings: - src/org/python/core/buffer/Base1DBuffer.java - src/org/python/core/buffer/BaseArrayBuffer.java - src/org/python/core/buffer/BaseNIOBuffer.java - src/org/python/core/buffer/SimpleNIOBuffer.java - src/org/python/core/buffer/Strided1DNIOBuffer.java - tests/java/org/python/core/ByteBufferTestSupport.java - tests/java/org/python/core/PyBufferNIOTest.java It makes sense for me to get this into the long delayed 2.7.1 - I do not see this change impacting any users, and it will clean up buffer protocol support. The alternative is that we have this change sit around and "bit rot" - not a good situation! Please merge away, with an updated NEWS entry, once the line endings are fixed. Thanks! - Jim On Wed, Aug 24, 2016 at 1:40 PM, Jim Baker <jim...@py...> wrote: > Jeff, > > Sorry, thanks for pinging about this. I will take a look today and get > back to you on that change. > > Other people on this list: feel free to bug me if I miss something. I'm a > very poor implementation of a select loop - always dropping things... But > retries usually get through. > > - Jim > > On Wed, Aug 24, 2016 at 4:02 AM, Jeff Allen <ja...@fa...> wrote: > >> Jim & all: >> >> I feel this has been sitting off to one side long enough. Do we feel safe >> that I can merge the underlying work? >> >> https://bitbucket.org/tournesol/jython-nio >> >> I'll write a short paragraph for NEWS as the last change. On a trivial >> matter of technique, that para goes above the "Jython 2.7.1rc" heading, >> ready for an rc2 heading above that when we get there, right? >> >> Jeff >> >> Jeff Allen >> >> >> On 19/07/2016 21:00, Jeff Allen wrote: >> >>> Thanks Stefan: nothing obviously crazy about the concept then. >>> >>> I'll take others' advice (Jim?) on whether this kind of change is too >>> much for 2.7.1, or feels safe. >>> >>> Concerning loops with calls in them, there's always an implementation >>> like that near the base of the hierarchy so that the non-contiguous case >>> is catered for, then the option (which I like to take up) of using a >>> bulk method in the contiguous sub-class. If we suddenly wanted to >>> support CopyTo/From ByteBuffer in the API, implementing it efficiently >>> could follow along. >>> >>> Main thing is you have your buffer protocol interface onto non-heap >>> storage to try when you can. >>> >>> Jeff >>> >>> Jeff Allen >>> >>> On 17/07/2016 15:26, Stefan Richthofer wrote: >>> >>>> Hello Jeff, >>>> >>>> sorry for the delay. I was (and still am) busy with adding NumPy >>>> support and it turned out that NumPy is okay with PyMemoryView_FromObject >>>> returning null for now (I suppose it has a fallback for that). It actually >>>> does call that method which is why I thought buffer protocol (which >>>> PyMemoryView_FromObject is based on) would be an urgent need for NumPy >>>> support. Of course I still want to add buffer protocol to JyNI, but won't >>>> find time to look at this before NumPy support moved on some more. So I did >>>> not yet take a detailed look at your work. However my main concern there >>>> would be to avoid that any index-iterating (NIO-bridge-)method would >>>> perform method calls within a loop, but instead is implemented using >>>> bulk-access methods. If this is already the case I would most likely have >>>> no further concerns. >>>> Thanks for adding getObj(); this is useful in any case. >>>> >>>> Do you think this would be bloat, nice-to-have, or really useful for >>>>> what you were hoping to do? >>>>> >>>> This sounds like it is mainly relevant for Java-integration and not so >>>> much for JyNI. Spontaneously I'd give it a "nice to have". >>>> >>>> To give you some definite clue regarding my time-management: I will >>>> resume work on BufferProtocol-front after >>>> a) Jython 2.7.1 was released >>>> b) JyNI 2.7-alpha.4 was released. >>>> >>>> >>>> Best, >>>> >>>> Stefan >>>> >>>> >>>> Gesendet: Freitag, 15. Juli 2016 um 09:42 Uhr >>>>> Von: "Jeff Allen" <ja...@fa...> >>>>> An: "Stefan Richthofer" <Ste...@gm...> >>>>> Cc: "Jython Developers" <jyt...@li...> >>>>> Betreff: Re: [Jython-dev] Jython buffer protocol >>>>> >>>>> Stefan: >>>>> >>>>> I recently pushed more changes to my bitbucket fork, including addition >>>>> of a getObj() to PyBuffer in response to your need to navigate to the >>>>> exporting object. >>>>> >>>>> The existing PyBuffer interface provides copyTo/From byte arrays. With >>>>> support for non-heap NIO storage it seems natural (and not too hard) to >>>>> add copyTo/From ByteBuffer. At present these are in the NIO >>>>> implementation, but not made interface items. Do you think this would >>>>> be >>>>> bloat, nice-to-have, or really useful for what you were hoping to do? >>>>> >>>>> Jeff >>>>> >>>>> Jeff Allen >>>>> >>>>> On 13/06/2016 01:04, Stefan Richthofer wrote: >>>>> >>>>>> Hey Jeff, >>>>>> thanks a lot for this work. I will take a closer look as soon as I >>>>>> find time. >>>>>> However, so far - quickly scrolling through some source-files - it >>>>>> looks pretty good. >>>>>> >>>>>> Best >>>>>> >>>>>> Stefan >>>>>> >>>>>> >>>>>> >>>>>> Gesendet: Samstag, 11. Juni 2016 um 11:37 Uhr >>>>>>> Von: "Jeff Allen" <ja...@fa...> >>>>>>> An: "Stefan Richthofer" <Ste...@gm...> >>>>>>> Cc: "Jython Developers" <jyt...@li...> >>>>>>> Betreff: Re: [Jython-dev] Jython buffer protocol >>>>>>> >>>>>>> Stefan: >>>>>>> >>>>>>> A sane version of the nio buffer work now exists for your delight at: >>>>>>> https://bitbucket.org/tournesol/jython-nio >>>>>>> >>>>>>> <snip> >>>>> >>>>> >>> ------------------------------------------------------------ >>> ------------------ >>> What NetFlow Analyzer can do for you? Monitors network bandwidth and >>> traffic >>> patterns at an interface-level. Reveals which users, apps, and protocols >>> are >>> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >>> J-Flow, sFlow and other flows. Make informed decisions using capacity >>> planning >>> reports.http://sdm.link/zohodev2dev >>> _______________________________________________ >>> Jython-dev mailing list >>> Jyt...@li... >>> https://lists.sourceforge.net/lists/listinfo/jython-dev >>> >>> >> > |
|
From: Jim B. <jim...@py...> - 2016-08-24 17:41:18
|
Jeff, Sorry, thanks for pinging about this. I will take a look today and get back to you on that change. Other people on this list: feel free to bug me if I miss something. I'm a very poor implementation of a select loop - always dropping things... But retries usually get through. - Jim On Wed, Aug 24, 2016 at 4:02 AM, Jeff Allen <ja...@fa...> wrote: > Jim & all: > > I feel this has been sitting off to one side long enough. Do we feel safe > that I can merge the underlying work? > > https://bitbucket.org/tournesol/jython-nio > > I'll write a short paragraph for NEWS as the last change. On a trivial > matter of technique, that para goes above the "Jython 2.7.1rc" heading, > ready for an rc2 heading above that when we get there, right? > > Jeff > > Jeff Allen > > > On 19/07/2016 21:00, Jeff Allen wrote: > >> Thanks Stefan: nothing obviously crazy about the concept then. >> >> I'll take others' advice (Jim?) on whether this kind of change is too >> much for 2.7.1, or feels safe. >> >> Concerning loops with calls in them, there's always an implementation >> like that near the base of the hierarchy so that the non-contiguous case >> is catered for, then the option (which I like to take up) of using a >> bulk method in the contiguous sub-class. If we suddenly wanted to >> support CopyTo/From ByteBuffer in the API, implementing it efficiently >> could follow along. >> >> Main thing is you have your buffer protocol interface onto non-heap >> storage to try when you can. >> >> Jeff >> >> Jeff Allen >> >> On 17/07/2016 15:26, Stefan Richthofer wrote: >> >>> Hello Jeff, >>> >>> sorry for the delay. I was (and still am) busy with adding NumPy support >>> and it turned out that NumPy is okay with PyMemoryView_FromObject returning >>> null for now (I suppose it has a fallback for that). It actually does call >>> that method which is why I thought buffer protocol (which >>> PyMemoryView_FromObject is based on) would be an urgent need for NumPy >>> support. Of course I still want to add buffer protocol to JyNI, but won't >>> find time to look at this before NumPy support moved on some more. So I did >>> not yet take a detailed look at your work. However my main concern there >>> would be to avoid that any index-iterating (NIO-bridge-)method would >>> perform method calls within a loop, but instead is implemented using >>> bulk-access methods. If this is already the case I would most likely have >>> no further concerns. >>> Thanks for adding getObj(); this is useful in any case. >>> >>> Do you think this would be bloat, nice-to-have, or really useful for >>>> what you were hoping to do? >>>> >>> This sounds like it is mainly relevant for Java-integration and not so >>> much for JyNI. Spontaneously I'd give it a "nice to have". >>> >>> To give you some definite clue regarding my time-management: I will >>> resume work on BufferProtocol-front after >>> a) Jython 2.7.1 was released >>> b) JyNI 2.7-alpha.4 was released. >>> >>> >>> Best, >>> >>> Stefan >>> >>> >>> Gesendet: Freitag, 15. Juli 2016 um 09:42 Uhr >>>> Von: "Jeff Allen" <ja...@fa...> >>>> An: "Stefan Richthofer" <Ste...@gm...> >>>> Cc: "Jython Developers" <jyt...@li...> >>>> Betreff: Re: [Jython-dev] Jython buffer protocol >>>> >>>> Stefan: >>>> >>>> I recently pushed more changes to my bitbucket fork, including addition >>>> of a getObj() to PyBuffer in response to your need to navigate to the >>>> exporting object. >>>> >>>> The existing PyBuffer interface provides copyTo/From byte arrays. With >>>> support for non-heap NIO storage it seems natural (and not too hard) to >>>> add copyTo/From ByteBuffer. At present these are in the NIO >>>> implementation, but not made interface items. Do you think this would be >>>> bloat, nice-to-have, or really useful for what you were hoping to do? >>>> >>>> Jeff >>>> >>>> Jeff Allen >>>> >>>> On 13/06/2016 01:04, Stefan Richthofer wrote: >>>> >>>>> Hey Jeff, >>>>> thanks a lot for this work. I will take a closer look as soon as I >>>>> find time. >>>>> However, so far - quickly scrolling through some source-files - it >>>>> looks pretty good. >>>>> >>>>> Best >>>>> >>>>> Stefan >>>>> >>>>> >>>>> >>>>> Gesendet: Samstag, 11. Juni 2016 um 11:37 Uhr >>>>>> Von: "Jeff Allen" <ja...@fa...> >>>>>> An: "Stefan Richthofer" <Ste...@gm...> >>>>>> Cc: "Jython Developers" <jyt...@li...> >>>>>> Betreff: Re: [Jython-dev] Jython buffer protocol >>>>>> >>>>>> Stefan: >>>>>> >>>>>> A sane version of the nio buffer work now exists for your delight at: >>>>>> https://bitbucket.org/tournesol/jython-nio >>>>>> >>>>>> <snip> >>>> >>>> >> ------------------------------------------------------------ >> ------------------ >> What NetFlow Analyzer can do for you? Monitors network bandwidth and >> traffic >> patterns at an interface-level. Reveals which users, apps, and protocols >> are >> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >> J-Flow, sFlow and other flows. Make informed decisions using capacity >> planning >> reports.http://sdm.link/zohodev2dev >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> >> > |
|
From: Jeff A. <ja...@fa...> - 2016-08-24 08:02:31
|
Jim & all: I feel this has been sitting off to one side long enough. Do we feel safe that I can merge the underlying work? https://bitbucket.org/tournesol/jython-nio I'll write a short paragraph for NEWS as the last change. On a trivial matter of technique, that para goes above the "Jython 2.7.1rc" heading, ready for an rc2 heading above that when we get there, right? Jeff Jeff Allen On 19/07/2016 21:00, Jeff Allen wrote: > Thanks Stefan: nothing obviously crazy about the concept then. > > I'll take others' advice (Jim?) on whether this kind of change is too > much for 2.7.1, or feels safe. > > Concerning loops with calls in them, there's always an implementation > like that near the base of the hierarchy so that the non-contiguous case > is catered for, then the option (which I like to take up) of using a > bulk method in the contiguous sub-class. If we suddenly wanted to > support CopyTo/From ByteBuffer in the API, implementing it efficiently > could follow along. > > Main thing is you have your buffer protocol interface onto non-heap > storage to try when you can. > > Jeff > > Jeff Allen > > On 17/07/2016 15:26, Stefan Richthofer wrote: >> Hello Jeff, >> >> sorry for the delay. I was (and still am) busy with adding NumPy support and it turned out that NumPy is okay with PyMemoryView_FromObject returning null for now (I suppose it has a fallback for that). It actually does call that method which is why I thought buffer protocol (which PyMemoryView_FromObject is based on) would be an urgent need for NumPy support. Of course I still want to add buffer protocol to JyNI, but won't find time to look at this before NumPy support moved on some more. So I did not yet take a detailed look at your work. However my main concern there would be to avoid that any index-iterating (NIO-bridge-)method would perform method calls within a loop, but instead is implemented using bulk-access methods. If this is already the case I would most likely have no further concerns. >> Thanks for adding getObj(); this is useful in any case. >> >>> Do you think this would be bloat, nice-to-have, or really useful for what you were hoping to do? >> This sounds like it is mainly relevant for Java-integration and not so much for JyNI. Spontaneously I'd give it a "nice to have". >> >> To give you some definite clue regarding my time-management: I will resume work on BufferProtocol-front after >> a) Jython 2.7.1 was released >> b) JyNI 2.7-alpha.4 was released. >> >> >> Best, >> >> Stefan >> >> >>> Gesendet: Freitag, 15. Juli 2016 um 09:42 Uhr >>> Von: "Jeff Allen" <ja...@fa...> >>> An: "Stefan Richthofer" <Ste...@gm...> >>> Cc: "Jython Developers" <jyt...@li...> >>> Betreff: Re: [Jython-dev] Jython buffer protocol >>> >>> Stefan: >>> >>> I recently pushed more changes to my bitbucket fork, including addition >>> of a getObj() to PyBuffer in response to your need to navigate to the >>> exporting object. >>> >>> The existing PyBuffer interface provides copyTo/From byte arrays. With >>> support for non-heap NIO storage it seems natural (and not too hard) to >>> add copyTo/From ByteBuffer. At present these are in the NIO >>> implementation, but not made interface items. Do you think this would be >>> bloat, nice-to-have, or really useful for what you were hoping to do? >>> >>> Jeff >>> >>> Jeff Allen >>> >>> On 13/06/2016 01:04, Stefan Richthofer wrote: >>>> Hey Jeff, >>>> thanks a lot for this work. I will take a closer look as soon as I find time. >>>> However, so far - quickly scrolling through some source-files - it looks pretty good. >>>> >>>> Best >>>> >>>> Stefan >>>> >>>> >>>> >>>>> Gesendet: Samstag, 11. Juni 2016 um 11:37 Uhr >>>>> Von: "Jeff Allen" <ja...@fa...> >>>>> An: "Stefan Richthofer" <Ste...@gm...> >>>>> Cc: "Jython Developers" <jyt...@li...> >>>>> Betreff: Re: [Jython-dev] Jython buffer protocol >>>>> >>>>> Stefan: >>>>> >>>>> A sane version of the nio buffer work now exists for your delight at: >>>>> https://bitbucket.org/tournesol/jython-nio >>>>> >>> <snip> >>> > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity planning > reports.http://sdm.link/zohodev2dev > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Jeff A. <ja...@fa...> - 2016-08-24 07:53:10
|
+1 for this. I write that tentatively because I only got my first taste of Gradle only this week. However, I'm no great fan of making human beings write XML and the Gradle DSL looks better to me at the moment. Jeff Allen On 19/08/2016 03:21, Darjus Loktevic wrote: > Might be useful for us as we have plans for moving away from Ant to > Gradle. Also would be useful for Jython users managing Python and Java > dependencies together > https://engineering.linkedin.com/blog/2016/08/introducing--py-gradle--an-open-source-python-plugin-for-gradle > |
|
From: Jython t. <st...@bu...> - 2016-08-19 16:10:23
|
ACTIVITY SUMMARY (2016-08-12 - 2016-08-19) Jython tracker at http://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 294 ( +1) closed 2239 ( +0) total 2533 ( +1) Open issues with patches: 28 Issues opened (1) ================= #2514: Jython Class.__subclasses__() does not match Python output (no http://bugs.jython.org/issue2514 opened by Myles Most recent 15 issues with no replies (15) ========================================== #2512: Values in built-in modules's __dict__ are â<reflected field http://bugs.jython.org/issue2512 #2511: Percent operator calls __getattr__('__getitem__') http://bugs.jython.org/issue2511 #2510: Crash after monkey-patching time.time with an unbound function http://bugs.jython.org/issue2510 #2507: Run "invokeFunction" in a thread does not inherit the "ScriptC http://bugs.jython.org/issue2507 #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #2429: cStringIO does not work with mutable objects implementing the http://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses http://bugs.jython.org/issue2367 #2330: full-build fails to copy CPython License http://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core http://bugs.jython.org/issue2230 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #2143: site-packages support in standalone jar http://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context http://bugs.jython.org/issue2142 #2077: marshal doesn't raise error when fed unmarshalable object http://bugs.jython.org/issue2077 #1925: Support loading java.sql.Drivers that aren't on the boot class http://bugs.jython.org/issue1925 #1917: No ctypes.c_char http://bugs.jython.org/issue1917 #1866: Parser does not have mismatch token error messages caught by B http://bugs.jython.org/issue1866 #1842: Add IBM i support to Jython http://bugs.jython.org/issue1842 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 Top 10 most discussed issues (1) ================================ #2514: Jython Class.__subclasses__() does not match Python output (no http://bugs.jython.org/issue2514 3 msgs |
|
From: Jim B. <jim...@py...> - 2016-08-19 15:06:09
|
Darjus, Thanks for taking a look at this. I believe the problem has been surfaced by the upgrade to Netty 4.1, which is giving us more feedback on a resource leak in test_socket. It's not the send fix itself. The solution to any Netty problem is to add another listener :), and joking aside, that should likely be the case here. - Jim On Fri, Aug 19, 2016 at 4:16 AM, Darjus Loktevic <da...@gm...> wrote: > Hey Nick, > > Looks like your socket.send change broke the regregression tests. It seems > that something is leaking/isn't being cleaned up as expected if the address > is still in use. Would appreciate you taking a look at this. > > https://circleci.com/gh/jythontools/jython/tree/master > > Cheers, > Darjus > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > > |
|
From: Darjus L. <da...@gm...> - 2016-08-19 10:16:29
|
Hey Nick, Looks like your socket.send change broke the regregression tests. It seems that something is leaking/isn't being cleaned up as expected if the address is still in use. Would appreciate you taking a look at this. https://circleci.com/gh/jythontools/jython/tree/master Cheers, Darjus |
|
From: Darjus L. <da...@gm...> - 2016-08-19 02:24:19
|
Agreed, Let's make this change in Jython3. We really cannot break this for Jython2. On Thu, Aug 18, 2016 at 3:49 PM Jeff Allen <ja...@fa...> wrote: > I agree with all this. As I said initially: > > It seems clear platform.uname should be consistent with platform.system, > platform.node, and so on. The documentation of platform.system > explicitly mentions 'Java' as an expected return. Not clear that it > should be consistent with os.uname. > > I also agree it is a pain that os.name should not reflect the real "disk > operating system" when so much code uses it like that. I think I saw > that this change has already been made in Jython 3. (Did I dream it?) > > However, I seem to observe (and it may be old code) that os.name gets > used in two ways: in one place to decide what functions might be > available, and in another to decide whether paths like "C:\Users" would > be valid. These uses conflict when you throw in jnr-posix. Perhaps, > against one's initial instincts, the availability of functions in the os > module is best inferred from platform.name rather than os.name. > > Jeff > > Jeff Allen > > On 17/08/2016 17:28, Jim Baker wrote: > > On Wed, Aug 17, 2016 at 9:22 AM, Stefan Richthofer > > <Ste...@gm... <mailto:Ste...@gm...>> wrote: > > > > Hey Jeff, > > thanks for your reply! > > > > I agree that in theory, os.uname and platform.uname should be > > consistent. > > And also platform.system with uname. However in practice, IMO it > > would cause much less trouble with not-Jython-aware modules if > > uname would provide native info rather than JVM-info. Jython-aware > > modules can obtain JVM-info from platform.java_ver anyway. On the > > other hand platform.uname always returned JVM-info in Jython until > > now, so there might be Jython-aware code out there relying on this. > > So as a compromise I'd suggest to let platform.uname behave like > > it always used to and os.uname provide native info such that > > non-Jython-aware modules have higher chance to work (especially > > relevant in JyNI; I wouldn't want to monkeypatch this!). os.uname > > should be save for existing Jython-aware modules, since it didn't > > exist at all in Jython prior to 2.7.1. > > > > > > +1, let's make this distinction. Keep os.uname with the new change; > > and make platform.uname go back to being Java information. This is why > > we have the platform module, vs the os module. > > > > I would keep this distinction for Jython 3. > > > > > > (It's already a constant pain that os.name <http://os.name> is > > 'java' and Alex Grönholm once pointed out in IRC this would switch > > to CPython behavior in Jython 3. IIRC this currently breaks pip in > > Jython on Windows. Maybe this can be fixed with a hack I use in > > JyNI, but that's rather a story for Jython 2.7.2.) > > > > > > Agreed about the constant pain. > > > > If we had the chance to go back in time to fix this for 2.7.0, I would > > have made os.name <http://os.name> be the underlying OS (eg 'posix' > > instead of 'java'). The os module should be about the underlying OS - > > it mostly is. So definitely we should fix for Jython 3. > > > > > > Summary > > If there are no objections I will make > > - os.uname provide native platform info (for practicability) > > - platform.uname provide JVM-info (for backward-compatibility) > > We still need to more confidently decide how os.uname should > > behave on Windows (however keeping current variant shouldn't be > > too bad I suppose). > > > > > > +1 > > > > Supporting os.uname on Windows make sense. > > > > - Jim > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Darjus L. <da...@gm...> - 2016-08-19 02:21:52
|
Might be useful for us as we have plans for moving away from Ant to Gradle. Also would be useful for Jython users managing Python and Java dependencies together https://engineering.linkedin.com/blog/2016/08/introducing--py-gradle--an-open-source-python-plugin-for-gradle |
|
From: Jeff A. <ja...@fa...> - 2016-08-18 05:48:19
|
I agree with all this. As I said initially: It seems clear platform.uname should be consistent with platform.system, platform.node, and so on. The documentation of platform.system explicitly mentions 'Java' as an expected return. Not clear that it should be consistent with os.uname. I also agree it is a pain that os.name should not reflect the real "disk operating system" when so much code uses it like that. I think I saw that this change has already been made in Jython 3. (Did I dream it?) However, I seem to observe (and it may be old code) that os.name gets used in two ways: in one place to decide what functions might be available, and in another to decide whether paths like "C:\Users" would be valid. These uses conflict when you throw in jnr-posix. Perhaps, against one's initial instincts, the availability of functions in the os module is best inferred from platform.name rather than os.name. Jeff Jeff Allen On 17/08/2016 17:28, Jim Baker wrote: > On Wed, Aug 17, 2016 at 9:22 AM, Stefan Richthofer > <Ste...@gm... <mailto:Ste...@gm...>> wrote: > > Hey Jeff, > thanks for your reply! > > I agree that in theory, os.uname and platform.uname should be > consistent. > And also platform.system with uname. However in practice, IMO it > would cause much less trouble with not-Jython-aware modules if > uname would provide native info rather than JVM-info. Jython-aware > modules can obtain JVM-info from platform.java_ver anyway. On the > other hand platform.uname always returned JVM-info in Jython until > now, so there might be Jython-aware code out there relying on this. > So as a compromise I'd suggest to let platform.uname behave like > it always used to and os.uname provide native info such that > non-Jython-aware modules have higher chance to work (especially > relevant in JyNI; I wouldn't want to monkeypatch this!). os.uname > should be save for existing Jython-aware modules, since it didn't > exist at all in Jython prior to 2.7.1. > > > +1, let's make this distinction. Keep os.uname with the new change; > and make platform.uname go back to being Java information. This is why > we have the platform module, vs the os module. > > I would keep this distinction for Jython 3. > > > (It's already a constant pain that os.name <http://os.name> is > 'java' and Alex Grönholm once pointed out in IRC this would switch > to CPython behavior in Jython 3. IIRC this currently breaks pip in > Jython on Windows. Maybe this can be fixed with a hack I use in > JyNI, but that's rather a story for Jython 2.7.2.) > > > Agreed about the constant pain. > > If we had the chance to go back in time to fix this for 2.7.0, I would > have made os.name <http://os.name> be the underlying OS (eg 'posix' > instead of 'java'). The os module should be about the underlying OS - > it mostly is. So definitely we should fix for Jython 3. > > > Summary > If there are no objections I will make > - os.uname provide native platform info (for practicability) > - platform.uname provide JVM-info (for backward-compatibility) > We still need to more confidently decide how os.uname should > behave on Windows (however keeping current variant shouldn't be > too bad I suppose). > > > +1 > > Supporting os.uname on Windows make sense. > > - Jim > |
|
From: Jim B. <jim...@py...> - 2016-08-17 16:57:12
|
On Wed, Aug 17, 2016 at 9:22 AM, Stefan Richthofer <Ste...@gm... > wrote: > Hey Jeff, > thanks for your reply! > > I agree that in theory, os.uname and platform.uname should be consistent. > And also platform.system with uname. However in practice, IMO it would > cause much less trouble with not-Jython-aware modules if uname would > provide native info rather than JVM-info. Jython-aware modules can obtain > JVM-info from platform.java_ver anyway. On the other hand platform.uname > always returned JVM-info in Jython until now, so there might be > Jython-aware code out there relying on this. > So as a compromise I'd suggest to let platform.uname behave like it always > used to and os.uname provide native info such that non-Jython-aware modules > have higher chance to work (especially relevant in JyNI; I wouldn't want to > monkeypatch this!). os.uname should be save for existing Jython-aware > modules, since it didn't exist at all in Jython prior to 2.7.1. > +1, let's make this distinction. Keep os.uname with the new change; and make platform.uname go back to being Java information. This is why we have the platform module, vs the os module. I would keep this distinction for Jython 3. > > (It's already a constant pain that os.name is 'java' and Alex Grönholm > once pointed out in IRC this would switch to CPython behavior in Jython 3. > IIRC this currently breaks pip in Jython on Windows. Maybe this can be > fixed with a hack I use in JyNI, but that's rather a story for Jython > 2.7.2.) > Agreed about the constant pain. If we had the chance to go back in time to fix this for 2.7.0, I would have made os.name be the underlying OS (eg 'posix' instead of 'java'). The os module should be about the underlying OS - it mostly is. So definitely we should fix for Jython 3. > > Summary > If there are no objections I will make > - os.uname provide native platform info (for practicability) > - platform.uname provide JVM-info (for backward-compatibility) > We still need to more confidently decide how os.uname should behave on > Windows (however keeping current variant shouldn't be too bad I suppose). > +1 Supporting os.uname on Windows make sense. - Jim |
|
From: Stefan R. <Ste...@gm...> - 2016-08-17 15:22:49
|
Hey Jeff,
thanks for your reply!
I agree that in theory, os.uname and platform.uname should be consistent.
And also platform.system with uname. However in practice, IMO it would cause much less trouble with not-Jython-aware modules if uname would provide native info rather than JVM-info. Jython-aware modules can obtain JVM-info from platform.java_ver anyway. On the other hand platform.uname always returned JVM-info in Jython until now, so there might be Jython-aware code out there relying on this.
So as a compromise I'd suggest to let platform.uname behave like it always used to and os.uname provide native info such that non-Jython-aware modules have higher chance to work (especially relevant in JyNI; I wouldn't want to monkeypatch this!). os.uname should be save for existing Jython-aware modules, since it didn't exist at all in Jython prior to 2.7.1.
(It's already a constant pain that os.name is 'java' and Alex Grönholm once pointed out in IRC this would switch to CPython behavior in Jython 3. IIRC this currently breaks pip in Jython on Windows. Maybe this can be fixed with a hack I use in JyNI, but that's rather a story for Jython 2.7.2.)
Summary
If there are no objections I will make
- os.uname provide native platform info (for practicability)
- platform.uname provide JVM-info (for backward-compatibility)
We still need to more confidently decide how os.uname should behave on Windows (however keeping current variant shouldn't be too bad I suppose).
Best
Stefan
> Gesendet: Sonntag, 14. August 2016 um 23:28 Uhr
> Von: "Jeff Allen" <ja...@fa...>
> An: jyt...@li...
> Betreff: Re: [Jython-dev] uname
>
> There's an argument that the *platform* of Jython is Java. Sometimes you
> want a clue about how the file system works (e.g. is "C:\" meaningful)
> and sometimes you want to guess what functions are available (as in the
> "Avaliability:" note in the documentation of the os module). It's not
> very clear (I'm looking at the 3.5.2 docs), of the several ways to
> interrogate os or platform, which is to be used as a clue for what purpose.
>
> It seems clear platform.uname should be consistent with platform.system,
> platform.note, and so on. The documentation of platform.system
> explicitly mentions 'Java' as an expected return. Not clear that it
> should be consistent with os.uname.
>
> Jeff Allen
>
> On 14/08/2016 04:26, Stefan Richthofer wrote:
> > Hey all,
> >
> > some months ago I added an implementation of os.uname to posix-module. In a portable fashion and with some extra effort I made this also work on Windows, because I liked the idea of Jython being resilient enough to support this posix-feature no matter if the platform was actually posix or not.
> >
> > Now I became aware of platform.uname, which I think is intended to work in such a portable manner, while os.uname should reflect system's uname in low-level sense. Indeed, also CPython features a Windows-equivalent of uname in platform.uname. Actually their approach wasn't too different to my re-invention of it in Jython's os.uname. With commit 9252c93e85754d6f3056407d3a67ae7633bdf813 I ensured that Jython's os.uname and also platform.uname match CPython's platform.uname on Windows exactly. (Can't use original CPython os.platform implementation, because it uses win32 module.)
> >
> > But...
> > Jython's platform.uname used to report JVM-info:
> > ('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
> > I already broke this behavior by adding os.uname, because inserting JVM-info is only a fallback if os.uname is not available to back os.platform:
> >
> > Jython 2.7.1b3
> > [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
> > Type "help", "copyright", "credits" or "license" for more information.
> >>>> import os, platform
> >>>> os.uname()
> > ('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64')
> >>>> platform.uname()
> > ('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64', '')
> >>>> exit()
> > You can still restore the old behavior by deleting os.uname (must be done before first call to platform.uname because of caching):
> >
> > Jython 2.7.1b3
> > [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
> > Type "help", "copyright", "credits" or "license" for more information.
> >>>> import os, platform
> >>>> del os.uname
> >>>> platform.uname()
> > ('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
> > Now I wonder whether this was the right choice. Also: Maybe Jython should not support os.uname on Windows; e.g. code in platform.py checks platform by looking if os.uname gives an attribute-error.
> > However I'd like to learn about your opinions on this (if you care at all), maybe we could even have a vote.
> > Does someone have or know an actual use-case needing os.platform to provide JVM-info?
> >
> > Current behavior:
> > - Never return JVM-info (is to some extend still available via platform.java_ver())
> > - os.uname and platform.uname behave equal (except that platform.uname appends processor info)
> > - os.uname is also implemented on Windows, equally to platform.uname in common result-elements
> >
> > Note that it is a no-opt to let os.uname provide JVM-info instead of platform-info, because native extensions as supported bY JyNI look at these values to condition on underlying platform (observed in PyOpenGL). This was the original reason why I needed to add os.uname support at all.
> >
> > top 1)
> > Should platform.uname be reverted to provide JVM-info, or should it be kept as it is now?
> >
> > top 2)
> > Should os.uname be workable on Windows?
> > If not, what should it do?
> >
> > a) throw NotImplementedError or return PyNotImplemented
> > (the 'right' way, but not what CPython-code would expect)
> > b) throw AttributeError
> > (satisfying typical checks for am-I-on-Windows/non-posix, unless someone uses hasattr(os, 'uname'))
> > c) Somehow truly remove os.uname on Windows (What would be the best way to achieve this?)
> > (would precisely resemble CPython-behavior, including hasattr(os, 'uname'))
> >
> >
> > Best
> >
> > Stefan
> >
> > ------------------------------------------------------------------------------
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports. http://sdm.link/zohodev2dev
> > _______________________________________________
> > Jython-dev mailing list
> > Jyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/jython-dev
> >
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
|
|
From: Darjus L. <da...@gm...> - 2016-08-17 02:05:32
|
Hey Guys, Spent some time yesterday and this morning fixing some of the lingering issues with CI and caching bug. With the CI passing, we should strive for an RC release ASAP. https://circleci.com/gh/jythontools/jython Cheers, Darjus |
|
From: Darjus L. <da...@gm...> - 2016-08-17 02:04:02
|
+1 On Wed, Aug 17, 2016 at 7:26 AM Stefan Richthofer <Ste...@gm...> wrote: > I think PySequenceList should implement java.util.List and would like to > add this. > - all classes that extend PySequenceList do implement List > - PySequenceList already declares all methods in List > > Is there a good reason why it is not? > > Best > > Stefan > > > ------------------------------------------------------------------------------ > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > |
|
From: Stefan R. <Ste...@gm...> - 2016-08-16 21:25:53
|
I think PySequenceList should implement java.util.List and would like to add this. - all classes that extend PySequenceList do implement List - PySequenceList already declares all methods in List Is there a good reason why it is not? Best Stefan |
|
From: Jeff A. <ja...@fa...> - 2016-08-14 21:29:17
|
There's an argument that the *platform* of Jython is Java. Sometimes you
want a clue about how the file system works (e.g. is "C:\" meaningful)
and sometimes you want to guess what functions are available (as in the
"Avaliability:" note in the documentation of the os module). It's not
very clear (I'm looking at the 3.5.2 docs), of the several ways to
interrogate os or platform, which is to be used as a clue for what purpose.
It seems clear platform.uname should be consistent with platform.system,
platform.note, and so on. The documentation of platform.system
explicitly mentions 'Java' as an expected return. Not clear that it
should be consistent with os.uname.
Jeff Allen
On 14/08/2016 04:26, Stefan Richthofer wrote:
> Hey all,
>
> some months ago I added an implementation of os.uname to posix-module. In a portable fashion and with some extra effort I made this also work on Windows, because I liked the idea of Jython being resilient enough to support this posix-feature no matter if the platform was actually posix or not.
>
> Now I became aware of platform.uname, which I think is intended to work in such a portable manner, while os.uname should reflect system's uname in low-level sense. Indeed, also CPython features a Windows-equivalent of uname in platform.uname. Actually their approach wasn't too different to my re-invention of it in Jython's os.uname. With commit 9252c93e85754d6f3056407d3a67ae7633bdf813 I ensured that Jython's os.uname and also platform.uname match CPython's platform.uname on Windows exactly. (Can't use original CPython os.platform implementation, because it uses win32 module.)
>
> But...
> Jython's platform.uname used to report JVM-info:
> ('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
> I already broke this behavior by adding os.uname, because inserting JVM-info is only a fallback if os.uname is not available to back os.platform:
>
> Jython 2.7.1b3
> [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import os, platform
>>>> os.uname()
> ('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64')
>>>> platform.uname()
> ('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64', '')
>>>> exit()
> You can still restore the old behavior by deleting os.uname (must be done before first call to platform.uname because of caching):
>
> Jython 2.7.1b3
> [Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import os, platform
>>>> del os.uname
>>>> platform.uname()
> ('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
> Now I wonder whether this was the right choice. Also: Maybe Jython should not support os.uname on Windows; e.g. code in platform.py checks platform by looking if os.uname gives an attribute-error.
> However I'd like to learn about your opinions on this (if you care at all), maybe we could even have a vote.
> Does someone have or know an actual use-case needing os.platform to provide JVM-info?
>
> Current behavior:
> - Never return JVM-info (is to some extend still available via platform.java_ver())
> - os.uname and platform.uname behave equal (except that platform.uname appends processor info)
> - os.uname is also implemented on Windows, equally to platform.uname in common result-elements
>
> Note that it is a no-opt to let os.uname provide JVM-info instead of platform-info, because native extensions as supported bY JyNI look at these values to condition on underlying platform (observed in PyOpenGL). This was the original reason why I needed to add os.uname support at all.
>
> top 1)
> Should platform.uname be reverted to provide JVM-info, or should it be kept as it is now?
>
> top 2)
> Should os.uname be workable on Windows?
> If not, what should it do?
>
> a) throw NotImplementedError or return PyNotImplemented
> (the 'right' way, but not what CPython-code would expect)
> b) throw AttributeError
> (satisfying typical checks for am-I-on-Windows/non-posix, unless someone uses hasattr(os, 'uname'))
> c) Somehow truly remove os.uname on Windows (What would be the best way to achieve this?)
> (would precisely resemble CPython-behavior, including hasattr(os, 'uname'))
>
>
> Best
>
> Stefan
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
|
|
From: Stefan R. <Ste...@gm...> - 2016-08-14 03:26:58
|
Hey all,
some months ago I added an implementation of os.uname to posix-module. In a portable fashion and with some extra effort I made this also work on Windows, because I liked the idea of Jython being resilient enough to support this posix-feature no matter if the platform was actually posix or not.
Now I became aware of platform.uname, which I think is intended to work in such a portable manner, while os.uname should reflect system's uname in low-level sense. Indeed, also CPython features a Windows-equivalent of uname in platform.uname. Actually their approach wasn't too different to my re-invention of it in Jython's os.uname. With commit 9252c93e85754d6f3056407d3a67ae7633bdf813 I ensured that Jython's os.uname and also platform.uname match CPython's platform.uname on Windows exactly. (Can't use original CPython os.platform implementation, because it uses win32 module.)
But...
Jython's platform.uname used to report JVM-info:
('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
I already broke this behavior by adding os.uname, because inserting JVM-info is only a fallback if os.uname is not available to back os.platform:
Jython 2.7.1b3
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, platform
>>> os.uname()
('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64')
>>> platform.uname()
('Linux', 'stefan-x200', '3.16.0-4-amd64', '#1 SMP Debian 3.16.7-ckt7-1 (2015-03-01)', 'x86_64', '')
>>> exit()
You can still restore the old behavior by deleting os.uname (must be done before first call to platform.uname because of caching):
Jython 2.7.1b3
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_101
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, platform
>>> del os.uname
>>> platform.uname()
('Java', 'stefan-x200', '1.8.0_101', 'Java HotSpot(TM) 64-Bit Server VM, 25.101-b13, Oracle Corporation', '', '')
>>>
Now I wonder whether this was the right choice. Also: Maybe Jython should not support os.uname on Windows; e.g. code in platform.py checks platform by looking if os.uname gives an attribute-error.
However I'd like to learn about your opinions on this (if you care at all), maybe we could even have a vote.
Does someone have or know an actual use-case needing os.platform to provide JVM-info?
Current behavior:
- Never return JVM-info (is to some extend still available via platform.java_ver())
- os.uname and platform.uname behave equal (except that platform.uname appends processor info)
- os.uname is also implemented on Windows, equally to platform.uname in common result-elements
Note that it is a no-opt to let os.uname provide JVM-info instead of platform-info, because native extensions as supported bY JyNI look at these values to condition on underlying platform (observed in PyOpenGL). This was the original reason why I needed to add os.uname support at all.
top 1)
Should platform.uname be reverted to provide JVM-info, or should it be kept as it is now?
top 2)
Should os.uname be workable on Windows?
If not, what should it do?
a) throw NotImplementedError or return PyNotImplemented
(the 'right' way, but not what CPython-code would expect)
b) throw AttributeError
(satisfying typical checks for am-I-on-Windows/non-posix, unless someone uses hasattr(os, 'uname'))
c) Somehow truly remove os.uname on Windows (What would be the best way to achieve this?)
(would precisely resemble CPython-behavior, including hasattr(os, 'uname'))
Best
Stefan
|
|
From: Jython t. <st...@bu...> - 2016-08-12 16:10:22
|
ACTIVITY SUMMARY (2016-08-05 - 2016-08-12) Jython tracker at http://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 293 ( +1) closed 2239 ( +0) total 2532 ( +1) Open issues with patches: 28 Issues opened (1) ================= #2513: Standard output is mixed up if Python scripts are evaluated in http://bugs.jython.org/issue2513 opened by yocaba Most recent 15 issues with no replies (15) ========================================== #2513: Standard output is mixed up if Python scripts are evaluated in http://bugs.jython.org/issue2513 #2512: Values in built-in modules's __dict__ are â<reflected field http://bugs.jython.org/issue2512 #2511: Percent operator calls __getattr__('__getitem__') http://bugs.jython.org/issue2511 #2510: Crash after monkey-patching time.time with an unbound function http://bugs.jython.org/issue2510 #2507: Run "invokeFunction" in a thread does not inherit the "ScriptC http://bugs.jython.org/issue2507 #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 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-08-08 08:10:26
|
Hi Alan, Early Access b130 <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+130.html>. Early Access b129 <https://jdk9.java.net/jigsaw/> (#5332) for JDK 9 with Project Jigsaw is available on java.net, summary of changes are listed here <http://download.java.net/java/jigsaw/archive/129/binaries/jdk-9+129.html> Early Access b04 <https://jdk8.java.net/download.html> for JDK 8u112 is available on java.net, summary of changes are listed here <http://download.java.net/java/jdk8u112/changes/jdk8u112-b04.html> Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland |
|
From: Jython t. <st...@bu...> - 2016-08-05 16:10:22
|
ACTIVITY SUMMARY (2016-07-29 - 2016-08-05) Jython tracker at http://bugs.jython.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 292 ( +3) closed 2239 ( +0) total 2531 ( +3) Open issues with patches: 28 Issues opened (3) ================= #2510: Crash after monkey-patching time.time with an unbound function http://bugs.jython.org/issue2510 opened by progval #2511: Percent operator calls __getattr__('__getitem__') http://bugs.jython.org/issue2511 opened by progval #2512: Values in built-in modules's __dict__ are â<reflected field http://bugs.jython.org/issue2512 opened by progval Most recent 15 issues with no replies (15) ========================================== #2512: Values in built-in modules's __dict__ are â<reflected field http://bugs.jython.org/issue2512 #2511: Percent operator calls __getattr__('__getitem__') http://bugs.jython.org/issue2511 #2510: Crash after monkey-patching time.time with an unbound function http://bugs.jython.org/issue2510 #2507: Run "invokeFunction" in a thread does not inherit the "ScriptC http://bugs.jython.org/issue2507 #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #2429: cStringIO does not work with mutable objects implementing the http://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses http://bugs.jython.org/issue2367 #2330: full-build fails to copy CPython License http://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core http://bugs.jython.org/issue2230 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #2143: site-packages support in standalone jar http://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context http://bugs.jython.org/issue2142 #2077: marshal doesn't raise error when fed unmarshalable object http://bugs.jython.org/issue2077 #1925: Support loading java.sql.Drivers that aren't on the boot class http://bugs.jython.org/issue1925 #1917: No ctypes.c_char http://bugs.jython.org/issue1917 #1866: Parser does not have mismatch token error messages caught by B http://bugs.jython.org/issue1866 #1842: Add IBM i support to Jython http://bugs.jython.org/issue1842 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 Top 10 most discussed issues (1) ================================ #2508: Jython non-blocking socket send() does not conform to Python's http://bugs.jython.org/issue2508 3 msgs |
|
From: Jython t. <st...@bu...> - 2016-07-29 16:10:22
|
ACTIVITY SUMMARY (2016-07-22 - 2016-07-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 289 ( +0) closed 2239 ( +0) total 2528 ( +0) Open issues with patches: 28 Most recent 15 issues with no replies (15) ========================================== #2507: Run "invokeFunction" in a thread does not inherit the "ScriptC http://bugs.jython.org/issue2507 #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 #2418: test_chdir subprocess tests fail on Windows http://bugs.jython.org/issue2418 #2410: Regression in PySystemStateTest (leading slash) http://bugs.jython.org/issue2410 #2408: Redo sre port for regular expression support http://bugs.jython.org/issue2408 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #2429: cStringIO does not work with mutable objects implementing the http://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses http://bugs.jython.org/issue2367 #2330: full-build fails to copy CPython License http://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core http://bugs.jython.org/issue2230 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #2143: site-packages support in standalone jar http://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context http://bugs.jython.org/issue2142 #2077: marshal doesn't raise error when fed unmarshalable object http://bugs.jython.org/issue2077 #1925: Support loading java.sql.Drivers that aren't on the boot class http://bugs.jython.org/issue1925 #1917: No ctypes.c_char http://bugs.jython.org/issue1917 #1866: Parser does not have mismatch token error messages caught by B http://bugs.jython.org/issue1866 #1842: Add IBM i support to Jython http://bugs.jython.org/issue1842 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 |
|
From: Jython t. <st...@bu...> - 2016-07-22 16:10:23
|
ACTIVITY SUMMARY (2016-07-15 - 2016-07-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 289 ( +0) closed 2239 ( +0) total 2528 ( +0) Open issues with patches: 28 Most recent 15 issues with no replies (15) ========================================== #2507: Run "invokeFunction" in a thread does not inherit the "ScriptC http://bugs.jython.org/issue2507 #2503: datetime.strptime doesn't handle Unicode strings when using su http://bugs.jython.org/issue2503 #2500: Loading default cacerts on client socket when specifying a def http://bugs.jython.org/issue2500 #2497: NameError: global name 'AdminConfig' is not defined in jython http://bugs.jython.org/issue2497 #2496: jython 2.7.0 homebrew on OSX fails http://bugs.jython.org/issue2496 #2494: Support for pydoc_data http://bugs.jython.org/issue2494 #2484: Codec encodings can exhaust permgen http://bugs.jython.org/issue2484 #2482: Publish U.S. ECCN for Jython http://bugs.jython.org/issue2482 #2479: Logging mechanism of Jython http://bugs.jython.org/issue2479 #2475: Backported python 3 pythlib and pathlib2 do not work b/c of me http://bugs.jython.org/issue2475 #2446: Support SNI for SSL/TLS http://bugs.jython.org/issue2446 #2422: test_classpathimporter fauls on Linux http://bugs.jython.org/issue2422 #2418: test_chdir subprocess tests fail on Windows http://bugs.jython.org/issue2418 #2410: Regression in PySystemStateTest (leading slash) http://bugs.jython.org/issue2410 #2408: Redo sre port for regular expression support http://bugs.jython.org/issue2408 Most recent 15 issues waiting for review (15) ============================================= #2462: SSL Handshake never happens even if do_handshake_on_connect=Tr http://bugs.jython.org/issue2462 #2429: cStringIO does not work with mutable objects implementing the http://bugs.jython.org/issue2429 #2367: Jython ignores custom __eq__ when hashing dict subclasses http://bugs.jython.org/issue2367 #2330: full-build fails to copy CPython License http://bugs.jython.org/issue2330 #2230: Jython evaluation blocks under heavy load with high multi-core http://bugs.jython.org/issue2230 #2228: [PATCH] Re-use "makeCompiledFilename" function where possible http://bugs.jython.org/issue2228 #2143: site-packages support in standalone jar http://bugs.jython.org/issue2143 #2142: Set Thread classloader when entering Jython context http://bugs.jython.org/issue2142 #2077: marshal doesn't raise error when fed unmarshalable object http://bugs.jython.org/issue2077 #1925: Support loading java.sql.Drivers that aren't on the boot class http://bugs.jython.org/issue1925 #1917: No ctypes.c_char http://bugs.jython.org/issue1917 #1866: Parser does not have mismatch token error messages caught by B http://bugs.jython.org/issue1866 #1842: Add IBM i support to Jython http://bugs.jython.org/issue1842 #1796: Jython doesn't support jar dir with colon's in it http://bugs.jython.org/issue1796 #1741: com.ziclix.python.sql.DataHandler calls wasNull without previo http://bugs.jython.org/issue1741 Top 10 most discussed issues (1) ================================ #2509: Demo/modjy_webapp is not working when deployed to Weblogic 12c http://bugs.jython.org/issue2509 4 msgs |
|
From: Rory O'D. <ror...@or...> - 2016-07-22 09:06:01
|
Hi Alan, Early Access b128 <https://jdk9.java.net/download/> for JDK 9 is available on java.net, summary of changes are listed here <http://www.java.net/download/java/jdk9/changes/jdk-9+128.html>. Early Access b127 <https://jdk9.java.net/jigsaw/> (#5304) for JDK 9 with Project Jigsaw is available on java.net, summary of changes are listed here <http://download.java.net/java/jigsaw/archive/127/binaries/jdk-9+127.html> Early Access b03 <https://jdk8.java.net/download.html> for JDK 8u112 is available on java.net, summary of changes are listed here <http://www.java.net/download/java/jdk8u112/changes/jdk8u112-b03.html> Alan Bateman posted new EA builds contain initial implementation of current proposals , more info [0] The jigsaw/jake forest has been updated with an initial implementation of the proposals that Mark brought to the jpms-spec-experts mailing list last week. For those that don't build from source then the EA build/downloads [1] has also been refreshed. Rgds,Rory [0] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008467.html [1] https://jdk9.java.net/jigsaw/ -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland |
|
From: Jeff A. <ja...@fa...> - 2016-07-19 20:01:01
|
Thanks Stefan: nothing obviously crazy about the concept then. I'll take others' advice (Jim?) on whether this kind of change is too much for 2.7.1, or feels safe. Concerning loops with calls in them, there's always an implementation like that near the base of the hierarchy so that the non-contiguous case is catered for, then the option (which I like to take up) of using a bulk method in the contiguous sub-class. If we suddenly wanted to support CopyTo/From ByteBuffer in the API, implementing it efficiently could follow along. Main thing is you have your buffer protocol interface onto non-heap storage to try when you can. Jeff Jeff Allen On 17/07/2016 15:26, Stefan Richthofer wrote: > Hello Jeff, > > sorry for the delay. I was (and still am) busy with adding NumPy support and it turned out that NumPy is okay with PyMemoryView_FromObject returning null for now (I suppose it has a fallback for that). It actually does call that method which is why I thought buffer protocol (which PyMemoryView_FromObject is based on) would be an urgent need for NumPy support. Of course I still want to add buffer protocol to JyNI, but won't find time to look at this before NumPy support moved on some more. So I did not yet take a detailed look at your work. However my main concern there would be to avoid that any index-iterating (NIO-bridge-)method would perform method calls within a loop, but instead is implemented using bulk-access methods. If this is already the case I would most likely have no further concerns. > Thanks for adding getObj(); this is useful in any case. > >> Do you think this would be bloat, nice-to-have, or really useful for what you were hoping to do? > This sounds like it is mainly relevant for Java-integration and not so much for JyNI. Spontaneously I'd give it a "nice to have". > > To give you some definite clue regarding my time-management: I will resume work on BufferProtocol-front after > a) Jython 2.7.1 was released > b) JyNI 2.7-alpha.4 was released. > > > Best, > > Stefan > > >> Gesendet: Freitag, 15. Juli 2016 um 09:42 Uhr >> Von: "Jeff Allen" <ja...@fa...> >> An: "Stefan Richthofer" <Ste...@gm...> >> Cc: "Jython Developers" <jyt...@li...> >> Betreff: Re: [Jython-dev] Jython buffer protocol >> >> Stefan: >> >> I recently pushed more changes to my bitbucket fork, including addition >> of a getObj() to PyBuffer in response to your need to navigate to the >> exporting object. >> >> The existing PyBuffer interface provides copyTo/From byte arrays. With >> support for non-heap NIO storage it seems natural (and not too hard) to >> add copyTo/From ByteBuffer. At present these are in the NIO >> implementation, but not made interface items. Do you think this would be >> bloat, nice-to-have, or really useful for what you were hoping to do? >> >> Jeff >> >> Jeff Allen >> >> On 13/06/2016 01:04, Stefan Richthofer wrote: >>> Hey Jeff, >>> thanks a lot for this work. I will take a closer look as soon as I find time. >>> However, so far - quickly scrolling through some source-files - it looks pretty good. >>> >>> Best >>> >>> Stefan >>> >>> >>> >>>> Gesendet: Samstag, 11. Juni 2016 um 11:37 Uhr >>>> Von: "Jeff Allen" <ja...@fa...> >>>> An: "Stefan Richthofer" <Ste...@gm...> >>>> Cc: "Jython Developers" <jyt...@li...> >>>> Betreff: Re: [Jython-dev] Jython buffer protocol >>>> >>>> Stefan: >>>> >>>> A sane version of the nio buffer work now exists for your delight at: >>>> https://bitbucket.org/tournesol/jython-nio >>>> >> <snip> >> |
|
From: Stefan R. <Ste...@gm...> - 2016-07-17 14:27:04
|
Hello Jeff, sorry for the delay. I was (and still am) busy with adding NumPy support and it turned out that NumPy is okay with PyMemoryView_FromObject returning null for now (I suppose it has a fallback for that). It actually does call that method which is why I thought buffer protocol (which PyMemoryView_FromObject is based on) would be an urgent need for NumPy support. Of course I still want to add buffer protocol to JyNI, but won't find time to look at this before NumPy support moved on some more. So I did not yet take a detailed look at your work. However my main concern there would be to avoid that any index-iterating (NIO-bridge-)method would perform method calls within a loop, but instead is implemented using bulk-access methods. If this is already the case I would most likely have no further concerns. Thanks for adding getObj(); this is useful in any case. >Do you think this would be bloat, nice-to-have, or really useful for what you were hoping to do? This sounds like it is mainly relevant for Java-integration and not so much for JyNI. Spontaneously I'd give it a "nice to have". To give you some definite clue regarding my time-management: I will resume work on BufferProtocol-front after a) Jython 2.7.1 was released b) JyNI 2.7-alpha.4 was released. Best, Stefan > Gesendet: Freitag, 15. Juli 2016 um 09:42 Uhr > Von: "Jeff Allen" <ja...@fa...> > An: "Stefan Richthofer" <Ste...@gm...> > Cc: "Jython Developers" <jyt...@li...> > Betreff: Re: [Jython-dev] Jython buffer protocol > > Stefan: > > I recently pushed more changes to my bitbucket fork, including addition > of a getObj() to PyBuffer in response to your need to navigate to the > exporting object. > > The existing PyBuffer interface provides copyTo/From byte arrays. With > support for non-heap NIO storage it seems natural (and not too hard) to > add copyTo/From ByteBuffer. At present these are in the NIO > implementation, but not made interface items. Do you think this would be > bloat, nice-to-have, or really useful for what you were hoping to do? > > Jeff > > Jeff Allen > > On 13/06/2016 01:04, Stefan Richthofer wrote: > > Hey Jeff, > > thanks a lot for this work. I will take a closer look as soon as I find time. > > However, so far - quickly scrolling through some source-files - it looks pretty good. > > > > Best > > > > Stefan > > > > > > > >> Gesendet: Samstag, 11. Juni 2016 um 11:37 Uhr > >> Von: "Jeff Allen" <ja...@fa...> > >> An: "Stefan Richthofer" <Ste...@gm...> > >> Cc: "Jython Developers" <jyt...@li...> > >> Betreff: Re: [Jython-dev] Jython buffer protocol > >> > >> Stefan: > >> > >> A sane version of the nio buffer work now exists for your delight at: > >> https://bitbucket.org/tournesol/jython-nio > >> > <snip> > |
101 messages has been excluded from this view by a project administrator.
