Unicode user and file names (and v2.7.1)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Unicode user and file names (and v2.7.1)

Jeff Allen-2

The numbering scheme for Python versions is quite well known.

https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work

One ought not to interpret the micro-version as more than bug-fix numbering. While I don't see a prohibition against skipping micro numbers I think it never seemed sensible to CPython when fear of double digits was an issue. So I start out opposed to the idea.

However, I recognise that 2.7, because there will never be a 2.8, has become a bit of a special case, and the micro-version might be read as a maturity claim. I like the logic of using the provenance of  ~/lib-python/2.7/test. So for "clarity in marketing" I'm not against a modest vorsprung.

I don't think Jython 2.7.1 is our last release in that version of the language. I'm sure we'll do more bug-fixes, and some back-ports from 3. (Like others, I've told myself that after this release, I'll give some time to 3.)

... so now, I find I've agreed with everything Stefan said!

To answer Stefan's question, the last mass update of lib-python was 2013/03/09 (https://hg.python.org/jython/rev/f763cd15ee2b). I don't believe the CPython change set it cites (README says its a v3.4), while CPython 2.7.4 was in beta at that date. We've pulled in specific parts of the CPython library since then to meet specific needs, but made no mass update. This alone seems a good reason for a further release.

Jeff Allen
On 22/05/2017 19:03, Stefan Richthofer wrote:
If we move away from 2.7.1 at all, the micro version should match the point where we updated python-lib last time IMO. I doubt it is 2.7.12. Maybe it's 2.7.6 or so I suspect (sorry if I should be wrong). Does someone now an efficient way to look it up?
A different numbering scheme for marketing purposes would be misleading and might disappoint users even more.
 
Also. I don't find Jython 2.7.1 should be the last Jython 2.7 or likewise. There will continue to be (maybe minor) progress and we should release this based on time intervals (6months was the plan, wasn't it?). IMO it's not so important that huge progress happens from version to version. Progress from 2.7.0 to 2.7.1 is actually far too large. Much more important is that there is progress at all and that it's displayed to the community by frequent releases.
 
-Stefan
 
Gesendet: Montag, 22. Mai 2017 um 19:50 Uhr
Von: "Jim Baker" [hidden email]
An: "Alan Kennedy" [hidden email]
Cc: "Darjus Loktevic" [hidden email], "Jeff Allen" [hidden email], "Stefan Richthofer" [hidden email], "Jython Developers" [hidden email]
Betreff: Re: [Jython-dev] Unicode user and file names (and v2.7.1)
Alan,
 
That's a great suggestion. 2.7 was specifically chosen to show this correspondence. In the past, we were not so as focused on compatibility, but most of the changes — and corresponding delays — in what we have been planning to call 2.7.1 are because of the continued development on CPython 2.7, by backporting fixes from successive versions of CPython 3.
 
So calling it 2.7.12 helps illustrate this. Any other thoughts on Alan's proposal?
 
- Jim
 
On Mon, May 22, 2017 at 11:25 AM, Alan Kennedy <[hidden email]> wrote:
Hi folks,
 
Great to see a solid 2.7.1 jython, and work begin in earnest on jython 3.
 
I have only one small suggestion to make: if jython 2.7.1 is going to be one of the last 2.7 releases, maybe consider numbering it in a way that indicates it is derived from the latest version of cpython 2.7.12. This could indicate that it is as up-to-date as it can be, i.e. not derived from cpython 2.7.1 and then abandoned.
 
Perception of abandonment is often a problem for jython: I think it's worth an effort to counter this mis-perception.
 
Regards,
 
Alan.
 
 
On Sun, May 21, 2017 at 4:35 PM, Darjus Loktevic <[hidden email]> wrote:
Hey Guys,
 
Regarding Jython3, looks like Isaiah has done a ton of work in 2016 (CCd). Not sure how far he progressed, but indeed merging will be hard and therefore I'd say we should not diverge further while developing on both branches, but instead try to finalize 2.7 and switch to Jython3 full-time.
 
Feel free to disagree, but here's my thinking on it:
  1. Release Jython 2.7.1
  2. Modernize the codebase. I think it's important for the project to feel modern for us to attract new contributors.
    1. Java8 as the minimum (may be too much for Jython2).
    2. Github/core-workflow
    3. (Ideally) ANTLR4 for both branches, but worst case, Jython3 only. ANTLR3 is not getting much love and ANTLR4 is quite different (does not generate AST).
    4. Gradle, directory structure.
  3. Develop Jython3 primarily. Only bugfixes for 2.7 series.
    1. Target 3.6 (really like the typing improvements).
    2. Merge JyNI if possible.
Cheers,
Darjus
 
On Sat, May 20, 2017 at 11:45 PM Jeff Allen <[hidden email]> wrote:

Thanks all. +1 on the RC. Nearly there with my bit.

I have fixed the  test_runpy failure James reported. It's not Linux-specific, just I had to quieten the unlink() error to see it on Windows. Bonus: we now pass the standard CPython test_runpy. The regrtest has been running one last time as I typed. I've pushed to https://bitbucket.org/tournesol/jython-utf8 just now.

I will next merge into the Jython trunk. That may not be totally smooth because of the pervasive change. And now I think about it, it's worth a note in NEWS. My time is a little limited today, so it could be much later today or tomorrow evening.

Jeff
 
Jeff Allen
On 20/05/2017 19:48, Jim Baker wrote:
+100
 
On Sat, May 20, 2017 at 12:33 PM, Darjus Loktevic <[hidden email]> wrote:
Agreed regarding not blocking on 2487. That whole area needs a rewrite and we could potentially utilize libraries available for Java 8.
 
Let's get Jeff's work in and do an RC?
 
Darjus
 


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unicode user and file names (and v2.7.1)

fwierzbicki@gmail.com
I am in agreement with Stefan as well. I think making 2.7.x
exceptional in that the numbering could convey the version of CPython
since so much extra work went into CPython 2.7.x. I'd be against doing
that for 3.x.x. Though we'd want to be honest and if the reality is
that it is based on (say) 2.7.6 at time of release, that should be the
number until we actually do get up to 2.7.12 (or later).

On Mon, May 22, 2017 at 1:15 PM, Jeff Allen <[hidden email]> wrote:

> The numbering scheme for Python versions is quite well known.
>
> https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work
>
> One ought not to interpret the micro-version as more than bug-fix numbering.
> While I don't see a prohibition against skipping micro numbers I think it
> never seemed sensible to CPython when fear of double digits was an issue. So
> I start out opposed to the idea.
>
> However, I recognise that 2.7, because there will never be a 2.8, has become
> a bit of a special case, and the micro-version might be read as a maturity
> claim. I like the logic of using the provenance of  ~/lib-python/2.7/test.
> So for "clarity in marketing" I'm not against a modest vorsprung.
>
> I don't think Jython 2.7.1 is our last release in that version of the
> language. I'm sure we'll do more bug-fixes, and some back-ports from 3.
> (Like others, I've told myself that after this release, I'll give some time
> to 3.)
>
> ... so now, I find I've agreed with everything Stefan said!
>
> To answer Stefan's question, the last mass update of lib-python was
> 2013/03/09 (https://hg.python.org/jython/rev/f763cd15ee2b). I don't believe
> the CPython change set it cites (README says its a v3.4), while CPython
> 2.7.4 was in beta at that date. We've pulled in specific parts of the
> CPython library since then to meet specific needs, but made no mass update.
> This alone seems a good reason for a further release.
>
> Jeff Allen
>
> On 22/05/2017 19:03, Stefan Richthofer wrote:
>
> If we move away from 2.7.1 at all, the micro version should match the point
> where we updated python-lib last time IMO. I doubt it is 2.7.12. Maybe it's
> 2.7.6 or so I suspect (sorry if I should be wrong). Does someone now an
> efficient way to look it up?
> A different numbering scheme for marketing purposes would be misleading and
> might disappoint users even more.
>
> Also. I don't find Jython 2.7.1 should be the last Jython 2.7 or likewise.
> There will continue to be (maybe minor) progress and we should release this
> based on time intervals (6months was the plan, wasn't it?). IMO it's not so
> important that huge progress happens from version to version. Progress from
> 2.7.0 to 2.7.1 is actually far too large. Much more important is that there
> is progress at all and that it's displayed to the community by frequent
> releases.
>
> -Stefan
>
> Gesendet: Montag, 22. Mai 2017 um 19:50 Uhr
> Von: "Jim Baker" <[hidden email]>
> An: "Alan Kennedy" <[hidden email]>
> Cc: "Darjus Loktevic" <[hidden email]>, "Jeff Allen" <[hidden email]>,
> "Stefan Richthofer" <[hidden email]>, "Jython Developers"
> <[hidden email]>
> Betreff: Re: [Jython-dev] Unicode user and file names (and v2.7.1)
> Alan,
>
> That's a great suggestion. 2.7 was specifically chosen to show this
> correspondence. In the past, we were not so as focused on compatibility, but
> most of the changes — and corresponding delays — in what we have been
> planning to call 2.7.1 are because of the continued development on CPython
> 2.7, by backporting fixes from successive versions of CPython 3.
>
> So calling it 2.7.12 helps illustrate this. Any other thoughts on Alan's
> proposal?
>
> - Jim
>
> On Mon, May 22, 2017 at 11:25 AM, Alan Kennedy <[hidden email]> wrote:
>>
>> Hi folks,
>>
>> Great to see a solid 2.7.1 jython, and work begin in earnest on jython 3.
>>
>> I have only one small suggestion to make: if jython 2.7.1 is going to be
>> one of the last 2.7 releases, maybe consider numbering it in a way that
>> indicates it is derived from the latest version of cpython 2.7.12. This
>> could indicate that it is as up-to-date as it can be, i.e. not derived from
>> cpython 2.7.1 and then abandoned.
>>
>> Perception of abandonment is often a problem for jython: I think it's
>> worth an effort to counter this mis-perception.
>>
>> Regards,
>>
>> Alan.
>>
>>
>> On Sun, May 21, 2017 at 4:35 PM, Darjus Loktevic <[hidden email]> wrote:
>>>
>>> Hey Guys,
>>>
>>> Regarding Jython3, looks like Isaiah has done a ton of work in 2016
>>> (CCd). Not sure how far he progressed, but indeed merging will be hard and
>>> therefore I'd say we should not diverge further while developing on both
>>> branches, but instead try to finalize 2.7 and switch to Jython3 full-time.
>>>
>>> Feel free to disagree, but here's my thinking on it:
>>>
>>> Release Jython 2.7.1
>>> Modernize the codebase. I think it's important for the project to feel
>>> modern for us to attract new contributors.
>>>
>>> Java8 as the minimum (may be too much for Jython2).
>>> Github/core-workflow
>>> (Ideally) ANTLR4 for both branches, but worst case, Jython3 only. ANTLR3
>>> is not getting much love and ANTLR4 is quite different (does not generate
>>> AST).
>>> Gradle, directory structure.
>>>
>>> Develop Jython3 primarily. Only bugfixes for 2.7 series.
>>>
>>> Target 3.6 (really like the typing improvements).
>>> Merge JyNI if possible.
>>>
>>> Cheers,
>>> Darjus
>>>
>>> On Sat, May 20, 2017 at 11:45 PM Jeff Allen <[hidden email]> wrote:
>>>>
>>>> Thanks all. +1 on the RC. Nearly there with my bit.
>>>>
>>>> I have fixed the  test_runpy failure James reported. It's not
>>>> Linux-specific, just I had to quieten the unlink() error to see it on
>>>> Windows. Bonus: we now pass the standard CPython test_runpy. The regrtest
>>>> has been running one last time as I typed. I've pushed to
>>>> https://bitbucket.org/tournesol/jython-utf8 just now.
>>>>
>>>> I will next merge into the Jython trunk. That may not be totally smooth
>>>> because of the pervasive change. And now I think about it, it's worth a note
>>>> in NEWS. My time is a little limited today, so it could be much later today
>>>> or tomorrow evening.
>>>>
>>>> Jeff
>>>>
>>>>
>>>> Jeff Allen
>>>>
>>>> On 20/05/2017 19:48, Jim Baker wrote:
>>>>
>>>> +100
>>>>
>>>> On Sat, May 20, 2017 at 12:33 PM, Darjus Loktevic <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Agreed regarding not blocking on 2487. That whole area needs a rewrite
>>>>> and we could potentially utilize libraries available for Java 8.
>>>>>
>>>>> Let's get Jeff's work in and do an RC?
>>>>>
>>>>> Darjus
>>>>>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unicode user and file names (and v2.7.1)

Javen O'Neal
Based on the discussion, I'm now against a 2.7.12, since the bugfix/micro part of the number shouldn't need to match CPython.

Furthermore, sys.version and sys.version_info wouldn't be able to handle a 4th number.

On May 22, 2017 17:59, "[hidden email]" <[hidden email]> wrote:
I am in agreement with Stefan as well. I think making 2.7.x
exceptional in that the numbering could convey the version of CPython
since so much extra work went into CPython 2.7.x. I'd be against doing
that for 3.x.x. Though we'd want to be honest and if the reality is
that it is based on (say) 2.7.6 at time of release, that should be the
number until we actually do get up to 2.7.12 (or later).

On Mon, May 22, 2017 at 1:15 PM, Jeff Allen <[hidden email]> wrote:
> The numbering scheme for Python versions is quite well known.
>
> https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work
>
> One ought not to interpret the micro-version as more than bug-fix numbering.
> While I don't see a prohibition against skipping micro numbers I think it
> never seemed sensible to CPython when fear of double digits was an issue. So
> I start out opposed to the idea.
>
> However, I recognise that 2.7, because there will never be a 2.8, has become
> a bit of a special case, and the micro-version might be read as a maturity
> claim. I like the logic of using the provenance of  ~/lib-python/2.7/test.
> So for "clarity in marketing" I'm not against a modest vorsprung.
>
> I don't think Jython 2.7.1 is our last release in that version of the
> language. I'm sure we'll do more bug-fixes, and some back-ports from 3.
> (Like others, I've told myself that after this release, I'll give some time
> to 3.)
>
> ... so now, I find I've agreed with everything Stefan said!
>
> To answer Stefan's question, the last mass update of lib-python was
> 2013/03/09 (https://hg.python.org/jython/rev/f763cd15ee2b). I don't believe
> the CPython change set it cites (README says its a v3.4), while CPython
> 2.7.4 was in beta at that date. We've pulled in specific parts of the
> CPython library since then to meet specific needs, but made no mass update.
> This alone seems a good reason for a further release.
>
> Jeff Allen
>
> On 22/05/2017 19:03, Stefan Richthofer wrote:
>
> If we move away from 2.7.1 at all, the micro version should match the point
> where we updated python-lib last time IMO. I doubt it is 2.7.12. Maybe it's
> 2.7.6 or so I suspect (sorry if I should be wrong). Does someone now an
> efficient way to look it up?
> A different numbering scheme for marketing purposes would be misleading and
> might disappoint users even more.
>
> Also. I don't find Jython 2.7.1 should be the last Jython 2.7 or likewise.
> There will continue to be (maybe minor) progress and we should release this
> based on time intervals (6months was the plan, wasn't it?). IMO it's not so
> important that huge progress happens from version to version. Progress from
> 2.7.0 to 2.7.1 is actually far too large. Much more important is that there
> is progress at all and that it's displayed to the community by frequent
> releases.
>
> -Stefan
>
> Gesendet: Montag, 22. Mai 2017 um 19:50 Uhr
> Von: "Jim Baker" <[hidden email]>
> An: "Alan Kennedy" <[hidden email]>
> Cc: "Darjus Loktevic" <[hidden email]>, "Jeff Allen" <[hidden email]>,
> "Stefan Richthofer" <[hidden email]>, "Jython Developers"
> <[hidden email]>
> Betreff: Re: [Jython-dev] Unicode user and file names (and v2.7.1)
> Alan,
>
> That's a great suggestion. 2.7 was specifically chosen to show this
> correspondence. In the past, we were not so as focused on compatibility, but
> most of the changes — and corresponding delays — in what we have been
> planning to call 2.7.1 are because of the continued development on CPython
> 2.7, by backporting fixes from successive versions of CPython 3.
>
> So calling it 2.7.12 helps illustrate this. Any other thoughts on Alan's
> proposal?
>
> - Jim
>
> On Mon, May 22, 2017 at 11:25 AM, Alan Kennedy <[hidden email]> wrote:
>>
>> Hi folks,
>>
>> Great to see a solid 2.7.1 jython, and work begin in earnest on jython 3.
>>
>> I have only one small suggestion to make: if jython 2.7.1 is going to be
>> one of the last 2.7 releases, maybe consider numbering it in a way that
>> indicates it is derived from the latest version of cpython 2.7.12. This
>> could indicate that it is as up-to-date as it can be, i.e. not derived from
>> cpython 2.7.1 and then abandoned.
>>
>> Perception of abandonment is often a problem for jython: I think it's
>> worth an effort to counter this mis-perception.
>>
>> Regards,
>>
>> Alan.
>>
>>
>> On Sun, May 21, 2017 at 4:35 PM, Darjus Loktevic <[hidden email]> wrote:
>>>
>>> Hey Guys,
>>>
>>> Regarding Jython3, looks like Isaiah has done a ton of work in 2016
>>> (CCd). Not sure how far he progressed, but indeed merging will be hard and
>>> therefore I'd say we should not diverge further while developing on both
>>> branches, but instead try to finalize 2.7 and switch to Jython3 full-time.
>>>
>>> Feel free to disagree, but here's my thinking on it:
>>>
>>> Release Jython 2.7.1
>>> Modernize the codebase. I think it's important for the project to feel
>>> modern for us to attract new contributors.
>>>
>>> Java8 as the minimum (may be too much for Jython2).
>>> Github/core-workflow
>>> (Ideally) ANTLR4 for both branches, but worst case, Jython3 only. ANTLR3
>>> is not getting much love and ANTLR4 is quite different (does not generate
>>> AST).
>>> Gradle, directory structure.
>>>
>>> Develop Jython3 primarily. Only bugfixes for 2.7 series.
>>>
>>> Target 3.6 (really like the typing improvements).
>>> Merge JyNI if possible.
>>>
>>> Cheers,
>>> Darjus
>>>
>>> On Sat, May 20, 2017 at 11:45 PM Jeff Allen <[hidden email]> wrote:
>>>>
>>>> Thanks all. +1 on the RC. Nearly there with my bit.
>>>>
>>>> I have fixed the  test_runpy failure James reported. It's not
>>>> Linux-specific, just I had to quieten the unlink() error to see it on
>>>> Windows. Bonus: we now pass the standard CPython test_runpy. The regrtest
>>>> has been running one last time as I typed. I've pushed to
>>>> https://bitbucket.org/tournesol/jython-utf8 just now.
>>>>
>>>> I will next merge into the Jython trunk. That may not be totally smooth
>>>> because of the pervasive change. And now I think about it, it's worth a note
>>>> in NEWS. My time is a little limited today, so it could be much later today
>>>> or tomorrow evening.
>>>>
>>>> Jeff
>>>>
>>>>
>>>> Jeff Allen
>>>>
>>>> On 20/05/2017 19:48, Jim Baker wrote:
>>>>
>>>> +100
>>>>
>>>> On Sat, May 20, 2017 at 12:33 PM, Darjus Loktevic <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Agreed regarding not blocking on 2487. That whole area needs a rewrite
>>>>> and we could potentially utilize libraries available for Java 8.
>>>>>
>>>>> Let's get Jeff's work in and do an RC?
>>>>>
>>>>> Darjus
>>>>>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating extlibs

Stefan Richthofer
In reply to this post by Jim Baker-2
Just noticed guava > 20.0 requires Java 8.
Strange thing: When building and running Jython on Java 8 with guava 22.0 all regrtests pass fine, but jar-standalone build is bad. Seems like our ant task fails to copy com.google -> org.python.google. Note that I double and triple checked I adjusted build.xml correctly. Is this related to jarjar? Is it maybe not compatible with Java8 jar-files? This might become a problem at some point.
Studying guava 22.0 release notes more properly showed that one shall use guava-22.0-android.jar to target Java 7 also on non-Android platforms. With guava-22.0-android.jar, building Jython jar-standalone works well indeed. regrtests also seem to pass then.
Ideas?
I'll update the linked repo from last email with guava-22.0-android.jar...
 
Gesendet: Montag, 22. Mai 2017 um 17:22 Uhr
Von: "Jim Baker" <[hidden email]>
An: "Stefan Richthofer" <[hidden email]>
Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] Updating extlibs
These changes look good to me. I will test out your patch, but all of this is in line with similar updates we have made in the past, usually around this time in the dev cycle.
 
I'm glad that moving to Gradle will make this re-pinning to upstream dependencies much easier going forward!
 
On Mon, May 22, 2017 at 8:46 AM, Stefan Richthofer <[hidden email]> wrote:
I uploaded the mentioned updates to
https://github.com/Stewori/jython.
See detailed changes at
https://github.com/Stewori/jython/commit/ee2b1263306f779bf8e9499afc6d02267648ac36

This might not yet work smoothly with Java 7, I will check and adjust that tomorrow.
Some packages were built from source using Java 8 and I'm not sure whether the gradle
scripts always configured Java 7 source compatibility properly.
However if some people could test it, especially on OSX, would be nice.

Best

Stefan


> Gesendet: Montag, 22. Mai 2017 um 04:07 Uhr
> Von: "Stefan Richthofer" <[hidden email]>
> An: "Jython Developers" <[hidden email]>
> Betreff: Updating extlibs
>
> Hey all,
> I spent some effort to explore feasibility of updating extlibs, especially minor versions (but sometimes even major version, e.g. guava and icu4j).
> My results so far, tested with regrtest on Linux and Windows 10 using Java8 ("okay" means I did not observe additional regrtest failures):
>
> ASM 5.0.4             -> 5.2     okay
> bouncycastle:
> bcpkix-jdk15on-1.54   -> 1.57    okay
> bcprov-jdk15on-1.54   -> 1.57    okay
>
> commons-compress-1.12 -> 1.14    okay
> guava-20.0            -> 22.0rc1 okay
> icu4j-58.1            -> 59_1    okay
> Netty 4.1.6           -> 4.1.11  okay
> java-sizeof-0.0.5     -- still current
> jffi-1.2.13           -> 1.2.15  okay
> jnr-ffi-2.1.0         -> 2.1.5   okay
> jnr-netdb-1.1.6       -- still current
> jnr-posix-3.0.31      -> 3.0.41  okay
> jnr-constants-0.9.5   -> 0.9.9   okay
> New platforms: jffi-aarch64-Linux.jar, jffi-ppc64le-Linux.jar, can be added...?
> Updated various other changed platform specific jars to jffi-1.2.15 (okay as far as tested)
> xercesImpl-2.11.0          -- still current
> jline-2.14.2               -> 2.14.3      okay (didn't try jline-3 this time)
> jarjar-1.4                 -- still current
> mysql-connector-java-5.1.6 -> 5.1.42      okay
> postgresql-8.3-603.jdbc4   -> 42.1.1-jre7 okay
>
> ----------These failed, so leaving them as it is:
> Antlr 3.1.3                -> 3.5.2  fails
> junit-4.10                 -> 4.12 or 4.11 class file for org.hamcrest.Matcher not found
> (staying with 4.10 for now to avoid new dependency on hamcrest-matcher)
> javax.servlet-api-2.5      -> 3.1.0  fails
> mockrunner      (better don't touch; whole structure changed)
> cpptasks        (better don't touch)
>
> - will be able to test with Java 7 on Tuesday, because I left my old laptop in the office.
> - will upload a fork containing these updates. Would be good if someone else could also test, especially on OSX.
> Maybe some stuff was not covered by regrtests. However the chance that updates solve issues and that they create issues are probably somewhat equal and I'd prefer to focus on fixing issues with current versions rather than older ones.
> So I'm strongly for getting this in if regrtests go through on Java 7 and OSX. 2.7.1RC-phase will be a good opportunity to confirm workability of these updates. Any concerns?
>
> -Stefan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unicode user and file names (and v2.7.1)

fwierzbicki@gmail.com
In reply to this post by Stefan Richthofer
On Sat, May 20, 2017 at 5:00 PM, Stefan Richthofer
<[hidden email]> wrote:
> I'd like to have http://bugs.jython.org/issue2536 "fixed" by removing that
> infinite recursion test; maybe we could even close this annoying issue then.
> A new Jython release should have reliable test suite. However I don't know
> the best way to remove or blacklist a certain test.
I don't think I saw anyone answer this (but the thread is long so I
may have missed it) but if you look in regrtest.py you'll see a list
starting around line 880, with one section called 'java'. That's a
list of tests that are deliberately skipped. That list hasn't been
looked at in a long time, and I bet there are tests in there that
actually shouldn't get skipped anymore... but that's a whole different
can of worms :)

-Frank

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unicode user and file names (and v2.7.1)

fwierzbicki@gmail.com
On Tue, May 23, 2017 at 5:29 PM, [hidden email]
<[hidden email]> wrote:

> On Sat, May 20, 2017 at 5:00 PM, Stefan Richthofer
> <[hidden email]> wrote:
>> I'd like to have http://bugs.jython.org/issue2536 "fixed" by removing that
>> infinite recursion test; maybe we could even close this annoying issue then.
>> A new Jython release should have reliable test suite. However I don't know
>> the best way to remove or blacklist a certain test.
> I don't think I saw anyone answer this (but the thread is long so I
> may have missed it) but if you look in regrtest.py you'll see a list
> starting around line 880, with one section called 'java'. That's a
> list of tests that are deliberately skipped. That list hasn't been
> looked at in a long time, and I bet there are tests in there that
> actually shouldn't get skipped anymore... but that's a whole different
> can of worms :)
Or if you are talking about a single test function and not a whole
test file something like this decorating the particular test will
work:

@unittest.skipIf(test_support.is_jython, "Not a valid test for Jython")

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unicode user and file names (and v2.7.1)

Jeff Allen-2
Sorry, I should have taken Stefan's hint.

Yes, if we need to exclude a whole test, then there are lists in
regrtest.py as Frank says. This is quite a crude tool, perhaps best
suited to tests whose entire purpose is irrelevant to Jython or that
interfere with subsequent tests.

It is better to skip individual tests as Frank also indicates. Some
tests really are not appropriate to Jython (mostly involving garbage
collection) because Jython is different and we're happy with it that
way. In other cases, it's a shortcoming of some kind and we should say
so in the skip message.

Ideally, the skip message or a comment in regrtest.py where the
exclusion happens, according to the approach taken, links to an open
issue. That way, we haven't just silenced the alarm.

Jeff

Jeff Allen

On 24/05/2017 01:35, [hidden email] wrote:

> On Tue, May 23, 2017 at 5:29 PM, [hidden email]
> <[hidden email]> wrote:
>> On Sat, May 20, 2017 at 5:00 PM, Stefan Richthofer
>> <[hidden email]> wrote:
>>> I'd like to have http://bugs.jython.org/issue2536 "fixed" by removing that
>>> infinite recursion test; maybe we could even close this annoying issue then.
>>> A new Jython release should have reliable test suite. However I don't know
>>> the best way to remove or blacklist a certain test.
>> I don't think I saw anyone answer this (but the thread is long so I
>> may have missed it) but if you look in regrtest.py you'll see a list
>> starting around line 880, with one section called 'java'. That's a
>> list of tests that are deliberately skipped. That list hasn't been
>> looked at in a long time, and I bet there are tests in there that
>> actually shouldn't get skipped anymore... but that's a whole different
>> can of worms :)
> Or if you are talking about a single test function and not a whole
> test file something like this decorating the particular test will
> work:
>
> @unittest.skipIf(test_support.is_jython, "Not a valid test for Jython")
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unicode user and file names (and v2.7.1)

Stefan Richthofer
Hey Jeff, Frank

thanks for coming back to this. However, I already helped myself to some extend.
I wouldn't have asked if it was as simple as adding @skip. That's an option, but maybe not the "right" way (I should have been more specific).

Specifically, the following tests should be excluded from test suite or moved to the very end (how to do that somewhat the "right" way?), because they potentially mess up guava internals such that later deadlocks can occur:

test_json: Features its own test-suite, so not sure how well it is possible to exclude certain test files using regrtest.py, i.e. Lib/json/tests/test_recursion.py. Relevant tests to exclude from that file are:

test_highly_nested_objects_decoding
test_highly_nested_objects_encoding
test_endless_recursion


test_isinstance:
test_subclass_recursion_limit
test_isinstance_recursion_limit

So, I'll just add @skipIf... to these, given that they are customized for Jython already, being in Lib. If you'd say we better exclude test_json and test_isinstance via regrtest.py or move them to the end, tell me...
Maybe we'd better continue with this on bugtracker/#2536, if at all.

Best

-Stefan


> Gesendet: Mittwoch, 24. Mai 2017 um 09:55 Uhr
> Von: "Jeff Allen" <[hidden email]>
> An: [hidden email]
> Betreff: Re: [Jython-dev] Unicode user and file names (and v2.7.1)
>
> Sorry, I should have taken Stefan's hint.
>
> Yes, if we need to exclude a whole test, then there are lists in
> regrtest.py as Frank says. This is quite a crude tool, perhaps best
> suited to tests whose entire purpose is irrelevant to Jython or that
> interfere with subsequent tests.
>
> It is better to skip individual tests as Frank also indicates. Some
> tests really are not appropriate to Jython (mostly involving garbage
> collection) because Jython is different and we're happy with it that
> way. In other cases, it's a shortcoming of some kind and we should say
> so in the skip message.
>
> Ideally, the skip message or a comment in regrtest.py where the
> exclusion happens, according to the approach taken, links to an open
> issue. That way, we haven't just silenced the alarm.
>
> Jeff
>
> Jeff Allen
>
> On 24/05/2017 01:35, [hidden email] wrote:
> > On Tue, May 23, 2017 at 5:29 PM, [hidden email]
> > <[hidden email]> wrote:
> >> On Sat, May 20, 2017 at 5:00 PM, Stefan Richthofer
> >> <[hidden email]> wrote:
> >>> I'd like to have http://bugs.jython.org/issue2536 "fixed" by removing that
> >>> infinite recursion test; maybe we could even close this annoying issue then.
> >>> A new Jython release should have reliable test suite. However I don't know
> >>> the best way to remove or blacklist a certain test.
> >> I don't think I saw anyone answer this (but the thread is long so I
> >> may have missed it) but if you look in regrtest.py you'll see a list
> >> starting around line 880, with one section called 'java'. That's a
> >> list of tests that are deliberately skipped. That list hasn't been
> >> looked at in a long time, and I bet there are tests in there that
> >> actually shouldn't get skipped anymore... but that's a whole different
> >> can of worms :)
> > Or if you are talking about a single test function and not a whole
> > test file something like this decorating the particular test will
> > work:
> >
> > @unittest.skipIf(test_support.is_jython, "Not a valid test for Jython")
> >
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Jython-dev mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/jython-dev
> >
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating extlibs

Stefan Richthofer
In reply to this post by Stefan Richthofer
Did someone test this on OSX? (reminder: https://github.com/Stewori/jython)
Or on Java 7?
I just tested on Java 7 and the only test I observe to fail unexpectedly is test_random:
 
test_random crashed -- <type 'exceptions.IOError'>: [Errno 13] Permission denied: '/data/workspace/linux/Jython_extlib/jython/dist/testreports/TEST-test.test_random.WichmannHill_TestBasicOps.xml'
 
The test passes when run individually.
 
However that is on my old laptop running Linux Mint Debian/LMDE2. It seems to be
some io error due to access rights and also occurs when running with Java8 on that
machine. Note that it passes with Java 8 on my current system. Unless this is due to
Java 8_111 vs Java 8_131, I guess it's system dependent. Strange though:
worked well before extlib update.
 
Still I'd suggest to get this stuff in for RC-phase, given that the test passes individually.
I'd merge this stuff as soon as someone reports OSX results.
 
-Stefan
 
 
Gesendet: Dienstag, 23. Mai 2017 um 23:57 Uhr
Von: "Stefan Richthofer" <[hidden email]>
An: "Jim Baker" <[hidden email]>
Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] Updating extlibs
Just noticed guava > 20.0 requires Java 8.
Strange thing: When building and running Jython on Java 8 with guava 22.0 all regrtests pass fine, but jar-standalone build is bad. Seems like our ant task fails to copy com.google -> org.python.google. Note that I double and triple checked I adjusted build.xml correctly. Is this related to jarjar? Is it maybe not compatible with Java8 jar-files? This might become a problem at some point.
Studying guava 22.0 release notes more properly showed that one shall use guava-22.0-android.jar to target Java 7 also on non-Android platforms. With guava-22.0-android.jar, building Jython jar-standalone works well indeed. regrtests also seem to pass then.
Ideas?
I'll update the linked repo from last email with guava-22.0-android.jar...
 
Gesendet: Montag, 22. Mai 2017 um 17:22 Uhr
Von: "Jim Baker" <[hidden email]>
An: "Stefan Richthofer" <[hidden email]>
Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] Updating extlibs
These changes look good to me. I will test out your patch, but all of this is in line with similar updates we have made in the past, usually around this time in the dev cycle.
 
I'm glad that moving to Gradle will make this re-pinning to upstream dependencies much easier going forward!
 
On Mon, May 22, 2017 at 8:46 AM, Stefan Richthofer <[hidden email]> wrote:
I uploaded the mentioned updates to
https://github.com/Stewori/jython.
See detailed changes at
https://github.com/Stewori/jython/commit/ee2b1263306f779bf8e9499afc6d02267648ac36

This might not yet work smoothly with Java 7, I will check and adjust that tomorrow.
Some packages were built from source using Java 8 and I'm not sure whether the gradle
scripts always configured Java 7 source compatibility properly.
However if some people could test it, especially on OSX, would be nice.

Best

Stefan


> Gesendet: Montag, 22. Mai 2017 um 04:07 Uhr
> Von: "Stefan Richthofer" <[hidden email]>
> An: "Jython Developers" <[hidden email]>
> Betreff: Updating extlibs
>
> Hey all,
> I spent some effort to explore feasibility of updating extlibs, especially minor versions (but sometimes even major version, e.g. guava and icu4j).
> My results so far, tested with regrtest on Linux and Windows 10 using Java8 ("okay" means I did not observe additional regrtest failures):
>
> ASM 5.0.4             -> 5.2     okay
> bouncycastle:
> bcpkix-jdk15on-1.54   -> 1.57    okay
> bcprov-jdk15on-1.54   -> 1.57    okay
>
> commons-compress-1.12 -> 1.14    okay
> guava-20.0            -> 22.0rc1 okay
> icu4j-58.1            -> 59_1    okay
> Netty 4.1.6           -> 4.1.11  okay
> java-sizeof-0.0.5     -- still current
> jffi-1.2.13           -> 1.2.15  okay
> jnr-ffi-2.1.0         -> 2.1.5   okay
> jnr-netdb-1.1.6       -- still current
> jnr-posix-3.0.31      -> 3.0.41  okay
> jnr-constants-0.9.5   -> 0.9.9   okay
> New platforms: jffi-aarch64-Linux.jar, jffi-ppc64le-Linux.jar, can be added...?
> Updated various other changed platform specific jars to jffi-1.2.15 (okay as far as tested)
> xercesImpl-2.11.0          -- still current
> jline-2.14.2               -> 2.14.3      okay (didn't try jline-3 this time)
> jarjar-1.4                 -- still current
> mysql-connector-java-5.1.6 -> 5.1.42      okay
> postgresql-8.3-603.jdbc4   -> 42.1.1-jre7 okay
>
> ----------These failed, so leaving them as it is:
> Antlr 3.1.3                -> 3.5.2  fails
> junit-4.10                 -> 4.12 or 4.11 class file for org.hamcrest.Matcher not found
> (staying with 4.10 for now to avoid new dependency on hamcrest-matcher)
> javax.servlet-api-2.5      -> 3.1.0  fails
> mockrunner      (better don't touch; whole structure changed)
> cpptasks        (better don't touch)
>
> - will be able to test with Java 7 on Tuesday, because I left my old laptop in the office.
> - will upload a fork containing these updates. Would be good if someone else could also test, especially on OSX.
> Maybe some stuff was not covered by regrtests. However the chance that updates solve issues and that they create issues are probably somewhat equal and I'd prefer to focus on fixing issues with current versions rather than older ones.
> So I'm strongly for getting this in if regrtests go through on Java 7 and OSX. 2.7.1RC-phase will be a good opportunity to confirm workability of these updates. Any concerns?
>
> -Stefan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ Jython-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Unicode user and file names (and v2.7.1)

Jeff Allen-2
In reply to this post by Stefan Richthofer
If it messes up later tests then, until it can be fixed, I think the
apparatus we have for excluding it applies. However, an extra test that
would fail in that case might be a good addition.

BTW when diagnosing that kind of thing, I've found it useful that
regrtest takes a list of tests on the command line, or in a file, and
runs them in the order given (and as many times as given).

+1 for adding fine-grain skips as you intend, mentioning the most
appropriate issue.

Jeff Allen

On 24/05/2017 17:27, Stefan Richthofer wrote:

> Hey Jeff, Frank
>
> thanks for coming back to this. However, I already helped myself to some extend.
> I wouldn't have asked if it was as simple as adding @skip. That's an option, but maybe not the "right" way (I should have been more specific).
>
> Specifically, the following tests should be excluded from test suite or moved to the very end (how to do that somewhat the "right" way?), because they potentially mess up guava internals such that later deadlocks can occur:
>
> test_json: Features its own test-suite, so not sure how well it is possible to exclude certain test files using regrtest.py, i.e. Lib/json/tests/test_recursion.py. Relevant tests to exclude from that file are:
>
> test_highly_nested_objects_decoding
> test_highly_nested_objects_encoding
> test_endless_recursion
>
>
> test_isinstance:
> test_subclass_recursion_limit
> test_isinstance_recursion_limit
>
> So, I'll just add @skipIf... to these, given that they are customized for Jython already, being in Lib. If you'd say we better exclude test_json and test_isinstance via regrtest.py or move them to the end, tell me...
> Maybe we'd better continue with this on bugtracker/#2536, if at all.
>
> Best
>
> -Stefan
>
>
>> Gesendet: Mittwoch, 24. Mai 2017 um 09:55 Uhr
>> Von: "Jeff Allen" <[hidden email]>
>> An: [hidden email]
>> Betreff: Re: [Jython-dev] Unicode user and file names (and v2.7.1)
>>
>> Sorry, I should have taken Stefan's hint.
>>
>> Yes, if we need to exclude a whole test, then there are lists in
>> regrtest.py as Frank says. This is quite a crude tool, perhaps best
>> suited to tests whose entire purpose is irrelevant to Jython or that
>> interfere with subsequent tests.
>>
>> It is better to skip individual tests as Frank also indicates. Some
>> tests really are not appropriate to Jython (mostly involving garbage
>> collection) because Jython is different and we're happy with it that
>> way. In other cases, it's a shortcoming of some kind and we should say
>> so in the skip message.
>>
>> Ideally, the skip message or a comment in regrtest.py where the
>> exclusion happens, according to the approach taken, links to an open
>> issue. That way, we haven't just silenced the alarm.
>>
>> Jeff
>>
>> Jeff Allen
>>
>> On 24/05/2017 01:35, [hidden email] wrote:
>>> On Tue, May 23, 2017 at 5:29 PM, [hidden email]
>>> <[hidden email]> wrote:
>>>> On Sat, May 20, 2017 at 5:00 PM, Stefan Richthofer
>>>> <[hidden email]> wrote:
>>>>> I'd like to have http://bugs.jython.org/issue2536 "fixed" by removing that
>>>>> infinite recursion test; maybe we could even close this annoying issue then.
>>>>> A new Jython release should have reliable test suite. However I don't know
>>>>> the best way to remove or blacklist a certain test.
>>>> I don't think I saw anyone answer this (but the thread is long so I
>>>> may have missed it) but if you look in regrtest.py you'll see a list
>>>> starting around line 880, with one section called 'java'. That's a
>>>> list of tests that are deliberately skipped. That list hasn't been
>>>> looked at in a long time, and I bet there are tests in there that
>>>> actually shouldn't get skipped anymore... but that's a whole different
>>>> can of worms :)
>>> Or if you are talking about a single test function and not a whole
>>> test file something like this decorating the particular test will
>>> work:
>>>
>>> @unittest.skipIf(test_support.is_jython, "Not a valid test for Jython")
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Jython-dev mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Jython-dev mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating extlibs

Jim Baker-2
In reply to this post by Stefan Richthofer
Stefan,

You can apply these updates to extlibs, based on my testing on OSX. More below.


I was able to run the following on both Java 7 and Java 8 on OSX:

pip/setuptools installation smoke test fully succeeds, using the manual test described in http://bugs.jython.org/issue2570 (we should look at automating, at least with a simple bash script)

regrtest. I did observe flakiness in test_socket_jy, which may require more rounds of waiting, but it does not appear to happen unless it's run in the context of other tests, so full runs of the regrtest. (And IIRC, appeared in the past before extlib update. It has been a well-known flaky test.) For Java 7, test_codecencodings_tw continues to not completely pass, almost certainly due to changes in underlying Java support (a bug fix that was not applied to Java 7). It has nothing to do with these extlib updates.

Note that test_socket is shaking out some problems, likely due to the Netty update further refining the exceptions it throws. It's worth noting that error states are not documented very well for either C sockets or Netty's rather different support, so we have to explore the implemented behavior. So one example I saw that should be fixed at some point (possibly not for 2.7.1, there will always be more bugs, and certainly higher priority ones IMHO at this time):

     [exec] Unhandled exception in thread started by <bound method BasicTCPTest.clientRun of testShutdown (test.test_socket.BasicTCPTest)>
     [exec] Traceback (most recent call last):
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/test/test_socket.py", line 186, in clientRun
     [exec]     self.clientSetUp()
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/test/test_socket.py", line 246, in clientSetUp
     [exec]     self.cli.connect((self.HOST, self.PORT))
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 1441, in meth
     [exec]     return getattr(self._sock,name)(*args)
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 935, in connect
     [exec]     self._connect(addr)
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 911, in _connect
     [exec]     self._handle_channel_future(self.connect_future, "connect")
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 384, in handle_exception
     [exec]     raise _map_exception(jlx)
     [exec] _socket.error: [Errno -1] Unmapped exception: io.netty.channel.AbstractChannel$AnnotatedSocketException: Invalid argument: localhost/127.0.0.1:50100 

I was unable to see this error thrown again, but we may have enough to still fix in the exception mapping code.

- Jim


On Wed, May 24, 2017 at 1:26 PM, Stefan Richthofer <[hidden email]> wrote:
Did someone test this on OSX? (reminder: https://github.com/Stewori/jython)
Or on Java 7?
I just tested on Java 7 and the only test I observe to fail unexpectedly is test_random:
 
test_random crashed -- <type 'exceptions.IOError'>: [Errno 13] Permission denied: '/data/workspace/linux/Jython_extlib/jython/dist/testreports/TEST-test.test_random.WichmannHill_TestBasicOps.xml'
 
The test passes when run individually.
 
However that is on my old laptop running Linux Mint Debian/LMDE2. It seems to be
some io error due to access rights and also occurs when running with Java8 on that
machine. Note that it passes with Java 8 on my current system. Unless this is due to
Java 8_111 vs Java 8_131, I guess it's system dependent. Strange though:
worked well before extlib update.
 
Still I'd suggest to get this stuff in for RC-phase, given that the test passes individually.
I'd merge this stuff as soon as someone reports OSX results.
 
-Stefan
 
 
Gesendet: Dienstag, 23. Mai 2017 um 23:57 Uhr
Von: "Stefan Richthofer" <[hidden email]>
An: "Jim Baker" <[hidden email]>

Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] Updating extlibs
Just noticed guava > 20.0 requires Java 8.
Strange thing: When building and running Jython on Java 8 with guava 22.0 all regrtests pass fine, but jar-standalone build is bad. Seems like our ant task fails to copy com.google -> org.python.google. Note that I double and triple checked I adjusted build.xml correctly. Is this related to jarjar? Is it maybe not compatible with Java8 jar-files? This might become a problem at some point.
Studying guava 22.0 release notes more properly showed that one shall use guava-22.0-android.jar to target Java 7 also on non-Android platforms. With guava-22.0-android.jar, building Jython jar-standalone works well indeed. regrtests also seem to pass then.
Ideas?
I'll update the linked repo from last email with guava-22.0-android.jar...
 
Gesendet: Montag, 22. Mai 2017 um 17:22 Uhr
Von: "Jim Baker" <[hidden email]>
An: "Stefan Richthofer" <[hidden email]>
Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] Updating extlibs
These changes look good to me. I will test out your patch, but all of this is in line with similar updates we have made in the past, usually around this time in the dev cycle.
 
I'm glad that moving to Gradle will make this re-pinning to upstream dependencies much easier going forward!
 
On Mon, May 22, 2017 at 8:46 AM, Stefan Richthofer <[hidden email]> wrote:
I uploaded the mentioned updates to
https://github.com/Stewori/jython.
See detailed changes at
https://github.com/Stewori/jython/commit/ee2b1263306f779bf8e9499afc6d02267648ac36

This might not yet work smoothly with Java 7, I will check and adjust that tomorrow.
Some packages were built from source using Java 8 and I'm not sure whether the gradle
scripts always configured Java 7 source compatibility properly.
However if some people could test it, especially on OSX, would be nice.

Best

Stefan


> Gesendet: Montag, 22. Mai 2017 um 04:07 Uhr
> Von: "Stefan Richthofer" <[hidden email]>
> An: "Jython Developers" <[hidden email]>
> Betreff: Updating extlibs
>
> Hey all,
> I spent some effort to explore feasibility of updating extlibs, especially minor versions (but sometimes even major version, e.g. guava and icu4j).
> My results so far, tested with regrtest on Linux and Windows 10 using Java8 ("okay" means I did not observe additional regrtest failures):
>
> ASM 5.0.4             -> 5.2     okay
> bouncycastle:
> bcpkix-jdk15on-1.54   -> 1.57    okay
> bcprov-jdk15on-1.54   -> 1.57    okay
>
> commons-compress-1.12 -> 1.14    okay
> guava-20.0            -> 22.0rc1 okay
> icu4j-58.1            -> 59_1    okay
> Netty 4.1.6           -> 4.1.11  okay
> java-sizeof-0.0.5     -- still current
> jffi-1.2.13           -> 1.2.15  okay
> jnr-ffi-2.1.0         -> 2.1.5   okay
> jnr-netdb-1.1.6       -- still current
> jnr-posix-3.0.31      -> 3.0.41  okay
> jnr-constants-0.9.5   -> 0.9.9   okay
> New platforms: jffi-aarch64-Linux.jar, jffi-ppc64le-Linux.jar, can be added...?
> Updated various other changed platform specific jars to jffi-1.2.15 (okay as far as tested)
> xercesImpl-2.11.0          -- still current
> jline-2.14.2               -> 2.14.3      okay (didn't try jline-3 this time)
> jarjar-1.4                 -- still current
> mysql-connector-java-5.1.6 -> 5.1.42      okay
> postgresql-8.3-603.jdbc4   -> 42.1.1-jre7 okay
>
> ----------These failed, so leaving them as it is:
> Antlr 3.1.3                -> 3.5.2  fails
> junit-4.10                 -> 4.12 or 4.11 class file for org.hamcrest.Matcher not found
> (staying with 4.10 for now to avoid new dependency on hamcrest-matcher)
> javax.servlet-api-2.5      -> 3.1.0  fails
> mockrunner      (better don't touch; whole structure changed)
> cpptasks        (better don't touch)
>
> - will be able to test with Java 7 on Tuesday, because I left my old laptop in the office.
> - will upload a fork containing these updates. Would be good if someone else could also test, especially on OSX.
> Maybe some stuff was not covered by regrtests. However the chance that updates solve issues and that they create issues are probably somewhat equal and I'd prefer to focus on fixing issues with current versions rather than older ones.
> So I'm strongly for getting this in if regrtests go through on Java 7 and OSX. 2.7.1RC-phase will be a good opportunity to confirm workability of these updates. Any concerns?
>
> -Stefan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ Jython-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating extlibs

Stefan Richthofer
> You can apply these updates to extlibs
 
From my point of view we can launch Jython 2.7.1-RC2 now.
 
- no open PRs on github left
- no release blockers left apparently except #2487
- all updates done as far as possible (python std-lib will be next challenge on this front)
 
So, I'd suggest everybody pushes last-minute work and Frank hits the release-button... :-)
What do you think?
 
 
Cheers!
 
-Stefan
 
 
Gesendet: Freitag, 26. Mai 2017 um 20:16 Uhr
Von: "Jim Baker" <[hidden email]>
An: "Stefan Richthofer" <[hidden email]>
Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] Updating extlibs
Stefan,
 
You can apply these updates to extlibs, based on my testing on OSX. More below.
 
 
I was able to run the following on both Java 7 and Java 8 on OSX:
 
pip/setuptools installation smoke test fully succeeds, using the manual test described in http://bugs.jython.org/issue2570 (we should look at automating, at least with a simple bash script)
 
regrtest. I did observe flakiness in test_socket_jy, which may require more rounds of waiting, but it does not appear to happen unless it's run in the context of other tests, so full runs of the regrtest. (And IIRC, appeared in the past before extlib update. It has been a well-known flaky test.) For Java 7, test_codecencodings_tw continues to not completely pass, almost certainly due to changes in underlying Java support (a bug fix that was not applied to Java 7). It has nothing to do with these extlib updates.
 
Note that test_socket is shaking out some problems, likely due to the Netty update further refining the exceptions it throws. It's worth noting that error states are not documented very well for either C sockets or Netty's rather different support, so we have to explore the implemented behavior. So one example I saw that should be fixed at some point (possibly not for 2.7.1, there will always be more bugs, and certainly higher priority ones IMHO at this time):
 
     [exec] Unhandled exception in thread started by <bound method BasicTCPTest.clientRun of testShutdown (test.test_socket.BasicTCPTest)>
     [exec] Traceback (most recent call last):
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/test/test_socket.py", line 186, in clientRun
     [exec]     self.clientSetUp()
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/test/test_socket.py", line 246, in clientSetUp
     [exec]     self.cli.connect((self.HOST, self.PORT))
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 1441, in meth
     [exec]     return getattr(self._sock,name)(*args)
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 935, in connect
     [exec]     self._connect(addr)
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 911, in _connect
     [exec]     self._handle_channel_future(self.connect_future, "connect")
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 384, in handle_exception
     [exec]     raise _map_exception(jlx)
     [exec] _socket.error: [Errno -1] Unmapped exception: io.netty.channel.AbstractChannel$AnnotatedSocketException: Invalid argument: localhost/127.0.0.1:50100 
 
I was unable to see this error thrown again, but we may have enough to still fix in the exception mapping code.
 
- Jim
 
 
On Wed, May 24, 2017 at 1:26 PM, Stefan Richthofer <[hidden email]> wrote:
Did someone test this on OSX? (reminder: https://github.com/Stewori/jython)
Or on Java 7?
I just tested on Java 7 and the only test I observe to fail unexpectedly is test_random:
 
test_random crashed -- <type 'exceptions.IOError'>: [Errno 13] Permission denied: '/data/workspace/linux/Jython_extlib/jython/dist/testreports/TEST-test.test_random.WichmannHill_TestBasicOps.xml'
 
The test passes when run individually.
 
However that is on my old laptop running Linux Mint Debian/LMDE2. It seems to be
some io error due to access rights and also occurs when running with Java8 on that
machine. Note that it passes with Java 8 on my current system. Unless this is due to
Java 8_111 vs Java 8_131, I guess it's system dependent. Strange though:
worked well before extlib update.
 
Still I'd suggest to get this stuff in for RC-phase, given that the test passes individually.
I'd merge this stuff as soon as someone reports OSX results.
 
-Stefan
 
 
Gesendet: Dienstag, 23. Mai 2017 um 23:57 Uhr
Von: "Stefan Richthofer" <[hidden email]>
An: "Jim Baker" <[hidden email]>

Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] Updating extlibs
Just noticed guava > 20.0 requires Java 8.
Strange thing: When building and running Jython on Java 8 with guava 22.0 all regrtests pass fine, but jar-standalone build is bad. Seems like our ant task fails to copy com.google -> org.python.google. Note that I double and triple checked I adjusted build.xml correctly. Is this related to jarjar? Is it maybe not compatible with Java8 jar-files? This might become a problem at some point.
Studying guava 22.0 release notes more properly showed that one shall use guava-22.0-android.jar to target Java 7 also on non-Android platforms. With guava-22.0-android.jar, building Jython jar-standalone works well indeed. regrtests also seem to pass then.
Ideas?
I'll update the linked repo from last email with guava-22.0-android.jar...
 
Gesendet: Montag, 22. Mai 2017 um 17:22 Uhr
Von: "Jim Baker" <[hidden email]>
An: "Stefan Richthofer" <[hidden email]>
Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] Updating extlibs
These changes look good to me. I will test out your patch, but all of this is in line with similar updates we have made in the past, usually around this time in the dev cycle.
 
I'm glad that moving to Gradle will make this re-pinning to upstream dependencies much easier going forward!
 
On Mon, May 22, 2017 at 8:46 AM, Stefan Richthofer <[hidden email]> wrote:
I uploaded the mentioned updates to
https://github.com/Stewori/jython.
See detailed changes at
https://github.com/Stewori/jython/commit/ee2b1263306f779bf8e9499afc6d02267648ac36

This might not yet work smoothly with Java 7, I will check and adjust that tomorrow.
Some packages were built from source using Java 8 and I'm not sure whether the gradle
scripts always configured Java 7 source compatibility properly.
However if some people could test it, especially on OSX, would be nice.

Best

Stefan


> Gesendet: Montag, 22. Mai 2017 um 04:07 Uhr
> Von: "Stefan Richthofer" <[hidden email]>
> An: "Jython Developers" <[hidden email]>
> Betreff: Updating extlibs
>
> Hey all,
> I spent some effort to explore feasibility of updating extlibs, especially minor versions (but sometimes even major version, e.g. guava and icu4j).
> My results so far, tested with regrtest on Linux and Windows 10 using Java8 ("okay" means I did not observe additional regrtest failures):
>
> ASM 5.0.4             -> 5.2     okay
> bouncycastle:
> bcpkix-jdk15on-1.54   -> 1.57    okay
> bcprov-jdk15on-1.54   -> 1.57    okay
>
> commons-compress-1.12 -> 1.14    okay
> guava-20.0            -> 22.0rc1 okay
> icu4j-58.1            -> 59_1    okay
> Netty 4.1.6           -> 4.1.11  okay
> java-sizeof-0.0.5     -- still current
> jffi-1.2.13           -> 1.2.15  okay
> jnr-ffi-2.1.0         -> 2.1.5   okay
> jnr-netdb-1.1.6       -- still current
> jnr-posix-3.0.31      -> 3.0.41  okay
> jnr-constants-0.9.5   -> 0.9.9   okay
> New platforms: jffi-aarch64-Linux.jar, jffi-ppc64le-Linux.jar, can be added...?
> Updated various other changed platform specific jars to jffi-1.2.15 (okay as far as tested)
> xercesImpl-2.11.0          -- still current
> jline-2.14.2               -> 2.14.3      okay (didn't try jline-3 this time)
> jarjar-1.4                 -- still current
> mysql-connector-java-5.1.6 -> 5.1.42      okay
> postgresql-8.3-603.jdbc4   -> 42.1.1-jre7 okay
>
> ----------These failed, so leaving them as it is:
> Antlr 3.1.3                -> 3.5.2  fails
> junit-4.10                 -> 4.12 or 4.11 class file for org.hamcrest.Matcher not found
> (staying with 4.10 for now to avoid new dependency on hamcrest-matcher)
> javax.servlet-api-2.5      -> 3.1.0  fails
> mockrunner      (better don't touch; whole structure changed)
> cpptasks        (better don't touch)
>
> - will be able to test with Java 7 on Tuesday, because I left my old laptop in the office.
> - will upload a fork containing these updates. Would be good if someone else could also test, especially on OSX.
> Maybe some stuff was not covered by regrtests. However the chance that updates solve issues and that they create issues are probably somewhat equal and I'd prefer to focus on fixing issues with current versions rather than older ones.
> So I'm strongly for getting this in if regrtests go through on Java 7 and OSX. 2.7.1RC-phase will be a good opportunity to confirm workability of these updates. Any concerns?
>
> -Stefan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ Jython-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: Updating extlibs

Jim Baker-2
Agreed. It's time for putting this release candidate out! I'm also glad about the timing, because this mean Stefan has a great base to build this summer's work on JyNI. I believe it's technically RC1 still because the last RC was a soft release, but Frank knows those specifics.

I just ran the "yolk smoke test" from http://bugs.jython.org/issue2570 one last time, just to make sure. Everything looks great!

After this we can look into:

1. Finally get jython.org revamped. I suggest the simplicity — and modern look — of GitHub pages, where we can host and then point jython.org accordingly.
2. Switch to the Gradle build that Darjus has been working on
3. Cut over to https://github.com/jython/jython with rewritten history that removes extlib jars for a subsequent release of 2.7.x, where x > 1 (maybe it's 12 for the next release, but we can decide later).

Lastly, I also felt it was important to highlight Stefan's contribution to helping finalize 2.7.1, as well as our appreciation to Google for supporting him this summer for the Google Summer of Code. First win for GSOC 2017 in other words. Duly noted as of https://hg.python.org/jython/rev/ab5434be88aa

- Jim



On May 26, 2017 7:24 PM, "Stefan Richthofer" <[hidden email]> wrote:
> You can apply these updates to extlibs
 
From my point of view we can launch Jython 2.7.1-RC2 now.
 
- no open PRs on github left
- no release blockers left apparently except #2487
- all updates done as far as possible (python std-lib will be next challenge on this front)
 
So, I'd suggest everybody pushes last-minute work and Frank hits the release-button... :-)
What do you think?
 
 
Cheers!
 
-Stefan
 
 
Gesendet: Freitag, 26. Mai 2017 um 20:16 Uhr
Von: "Jim Baker" <[hidden email]>
An: "Stefan Richthofer" <[hidden email]>
Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] Updating extlibs
Stefan,
 
You can apply these updates to extlibs, based on my testing on OSX. More below.
 
 
I was able to run the following on both Java 7 and Java 8 on OSX:
 
pip/setuptools installation smoke test fully succeeds, using the manual test described in http://bugs.jython.org/issue2570 (we should look at automating, at least with a simple bash script)
 
regrtest. I did observe flakiness in test_socket_jy, which may require more rounds of waiting, but it does not appear to happen unless it's run in the context of other tests, so full runs of the regrtest. (And IIRC, appeared in the past before extlib update. It has been a well-known flaky test.) For Java 7, test_codecencodings_tw continues to not completely pass, almost certainly due to changes in underlying Java support (a bug fix that was not applied to Java 7). It has nothing to do with these extlib updates.
 
Note that test_socket is shaking out some problems, likely due to the Netty update further refining the exceptions it throws. It's worth noting that error states are not documented very well for either C sockets or Netty's rather different support, so we have to explore the implemented behavior. So one example I saw that should be fixed at some point (possibly not for 2.7.1, there will always be more bugs, and certainly higher priority ones IMHO at this time):
 
     [exec] Unhandled exception in thread started by <bound method BasicTCPTest.clientRun of testShutdown (test.test_socket.BasicTCPTest)>
     [exec] Traceback (most recent call last):
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/test/test_socket.py", line 186, in clientRun
     [exec]     self.clientSetUp()
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/test/test_socket.py", line 246, in clientSetUp
     [exec]     self.cli.connect((self.HOST, self.PORT))
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 1441, in meth
     [exec]     return getattr(self._sock,name)(*args)
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 935, in connect
     [exec]     self._connect(addr)
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 911, in _connect
     [exec]     self._handle_channel_future(self.connect_future, "connect")
     [exec]   File "/Users/jbaker/jythondev/jython-extlibs/dist/Lib/_socket.py", line 384, in handle_exception
     [exec]     raise _map_exception(jlx)
     [exec] _socket.error: [Errno -1] Unmapped exception: io.netty.channel.AbstractChannel$AnnotatedSocketException: Invalid argument: localhost/127.0.0.1:50100 
 
I was unable to see this error thrown again, but we may have enough to still fix in the exception mapping code.
 
- Jim
 
 
On Wed, May 24, 2017 at 1:26 PM, Stefan Richthofer <[hidden email]> wrote:
Did someone test this on OSX? (reminder: https://github.com/Stewori/jython)
Or on Java 7?
I just tested on Java 7 and the only test I observe to fail unexpectedly is test_random:
 
test_random crashed -- <type 'exceptions.IOError'>: [Errno 13] Permission denied: '/data/workspace/linux/Jython_extlib/jython/dist/testreports/TEST-test.test_random.WichmannHill_TestBasicOps.xml'
 
The test passes when run individually.
 
However that is on my old laptop running Linux Mint Debian/LMDE2. It seems to be
some io error due to access rights and also occurs when running with Java8 on that
machine. Note that it passes with Java 8 on my current system. Unless this is due to
Java 8_111 vs Java 8_131, I guess it's system dependent. Strange though:
worked well before extlib update.
 
Still I'd suggest to get this stuff in for RC-phase, given that the test passes individually.
I'd merge this stuff as soon as someone reports OSX results.
 
-Stefan
 
 
Gesendet: Dienstag, 23. Mai 2017 um 23:57 Uhr
Von: "Stefan Richthofer" <[hidden email]>
An: "Jim Baker" <[hidden email]>

Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] Updating extlibs
Just noticed guava > 20.0 requires Java 8.
Strange thing: When building and running Jython on Java 8 with guava 22.0 all regrtests pass fine, but jar-standalone build is bad. Seems like our ant task fails to copy com.google -> org.python.google. Note that I double and triple checked I adjusted build.xml correctly. Is this related to jarjar? Is it maybe not compatible with Java8 jar-files? This might become a problem at some point.
Studying guava 22.0 release notes more properly showed that one shall use guava-22.0-android.jar to target Java 7 also on non-Android platforms. With guava-22.0-android.jar, building Jython jar-standalone works well indeed. regrtests also seem to pass then.
Ideas?
I'll update the linked repo from last email with guava-22.0-android.jar...
 
Gesendet: Montag, 22. Mai 2017 um 17:22 Uhr
Von: "Jim Baker" <[hidden email]>
An: "Stefan Richthofer" <[hidden email]>
Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] Updating extlibs
These changes look good to me. I will test out your patch, but all of this is in line with similar updates we have made in the past, usually around this time in the dev cycle.
 
I'm glad that moving to Gradle will make this re-pinning to upstream dependencies much easier going forward!
 
On Mon, May 22, 2017 at 8:46 AM, Stefan Richthofer <[hidden email]> wrote:
I uploaded the mentioned updates to
https://github.com/Stewori/jython.
See detailed changes at
https://github.com/Stewori/jython/commit/ee2b1263306f779bf8e9499afc6d02267648ac36

This might not yet work smoothly with Java 7, I will check and adjust that tomorrow.
Some packages were built from source using Java 8 and I'm not sure whether the gradle
scripts always configured Java 7 source compatibility properly.
However if some people could test it, especially on OSX, would be nice.

Best

Stefan


> Gesendet: Montag, 22. Mai 2017 um 04:07 Uhr
> Von: "Stefan Richthofer" <[hidden email]>
> An: "Jython Developers" <[hidden email]>
> Betreff: Updating extlibs
>
> Hey all,
> I spent some effort to explore feasibility of updating extlibs, especially minor versions (but sometimes even major version, e.g. guava and icu4j).
> My results so far, tested with regrtest on Linux and Windows 10 using Java8 ("okay" means I did not observe additional regrtest failures):
>
> ASM 5.0.4             -> 5.2     okay
> bouncycastle:
> bcpkix-jdk15on-1.54   -> 1.57    okay
> bcprov-jdk15on-1.54   -> 1.57    okay
>
> commons-compress-1.12 -> 1.14    okay
> guava-20.0            -> 22.0rc1 okay
> icu4j-58.1            -> 59_1    okay
> Netty 4.1.6           -> 4.1.11  okay
> java-sizeof-0.0.5     -- still current
> jffi-1.2.13           -> 1.2.15  okay
> jnr-ffi-2.1.0         -> 2.1.5   okay
> jnr-netdb-1.1.6       -- still current
> jnr-posix-3.0.31      -> 3.0.41  okay
> jnr-constants-0.9.5   -> 0.9.9   okay
> New platforms: jffi-aarch64-Linux.jar, jffi-ppc64le-Linux.jar, can be added...?
> Updated various other changed platform specific jars to jffi-1.2.15 (okay as far as tested)
> xercesImpl-2.11.0          -- still current
> jline-2.14.2               -> 2.14.3      okay (didn't try jline-3 this time)
> jarjar-1.4                 -- still current
> mysql-connector-java-5.1.6 -> 5.1.42      okay
> postgresql-8.3-603.jdbc4   -> 42.1.1-jre7 okay
>
> ----------These failed, so leaving them as it is:
> Antlr 3.1.3                -> 3.5.2  fails
> junit-4.10                 -> 4.12 or 4.11 class file for org.hamcrest.Matcher not found
> (staying with 4.10 for now to avoid new dependency on hamcrest-matcher)
> javax.servlet-api-2.5      -> 3.1.0  fails
> mockrunner      (better don't touch; whole structure changed)
> cpptasks        (better don't touch)
>
> - will be able to test with Java 7 on Tuesday, because I left my old laptop in the office.
> - will upload a fork containing these updates. Would be good if someone else could also test, especially on OSX.
> Maybe some stuff was not covered by regrtests. However the chance that updates solve issues and that they create issues are probably somewhat equal and I'd prefer to focus on fixing issues with current versions rather than older ones.
> So I'm strongly for getting this in if regrtests go through on Java 7 and OSX. 2.7.1RC-phase will be a good opportunity to confirm workability of these updates. Any concerns?
>
> -Stefan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ Jython-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

2.7.1rc, to infinity and beyond!

Jeff Allen-2
Excellent news! A lot has gone on between 2.7.0 and 2.7.1. it's good to
find we've all feel "done"at the same time :)

Small typo in your front page: "many others to thanks".

I have a weak preference for calling it RC2 given there was change after
RC1. I think RC1 still identifies a release, even if it was announced
softly, and what we have now is different.

There's a bit more to cutting over to Git than declaring it so. I've
been watching CPython do this with the corner of one eye. We will have
both bugs.jython.org and Git pull requests for a while ... essentially
forever. There was some integration work (which we should steal, but
that depends, I suspect, on upgrading the tracker) and conventions for
how to refer to one from the other. It was tough at points because of
disagreement on how it were best done, but we can just go along with
their conclusion. And s/bpo/bjo/.

Jeff Allen

On 27/05/2017 01:12, Jim Baker wrote:

> Agreed. It's time for putting this release candidate out! I'm also
> glad about the timing, because this mean Stefan has a great base to
> build this summer's work on JyNI. I believe it's technically RC1 still
> because the last RC was a soft release, but Frank knows those specifics.
>
> I just ran the "yolk smoke test" from http://bugs.jython.org/issue2570 
> <http://bugs.jython.org/issue2570> one last time, just to make sure.
> Everything looks great!
>
> After this we can look into:
>
> 1. Finally get jython.org <http://jython.org> revamped. I suggest the
> simplicity — and modern look — of GitHub pages, where we can host and
> then point jython.org <http://jython.org> accordingly.
> 2. Switch to the Gradle build that Darjus has been working on
> 3. Cut over to https://github.com/jython/jython with rewritten history
> that removes extlib jars for a subsequent release of 2.7.x, where x >
> 1 (maybe it's 12 for the next release, but we can decide later).
>
> Lastly, I also felt it was important to highlight Stefan's
> contribution to helping finalize 2.7.1, as well as our appreciation to
> Google for supporting him this summer for the Google Summer of Code.
> First win for GSOC 2017 in other words. Duly noted as of
> https://hg.python.org/jython/rev/ab5434be88aa
>
> - Jim
>
>
>
> On May 26, 2017 7:24 PM, "Stefan Richthofer" <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     > You can apply these updates to extlibs
>     Done as of https://hg.python.org/jython/rev/f6b3ddbc1df8
>     <https://hg.python.org/jython/rev/f6b3ddbc1df8>.
>     From my point of view we can launch Jython 2.7.1-RC2 now.
>     - no open PRs on github left
>     - no release blockers left apparently except #2487
>     - all updates done as far as possible (python std-lib will be next
>     challenge on this front)
>     So, I'd suggest everybody pushes last-minute work and Frank hits
>     the release-button... :-)
>     What do you think?
>     Cheers!
>     -Stefan
>
<snip>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7.1rc, to infinity and beyond!

Adam Burke-2
I know I'm a lurker and not an active dev, but I'd prefer the rc2 name as well, fwiw.

Cheers
Adam

On 27 May 2017 at 15:33, Jeff Allen <[hidden email]> wrote:
Excellent news! A lot has gone on between 2.7.0 and 2.7.1. it's good to find we've all feel "done"at the same time :)

Small typo in your front page: "many others to thanks".

I have a weak preference for calling it RC2 given there was change after RC1. I think RC1 still identifies a release, even if it was announced softly, and what we have now is different.

There's a bit more to cutting over to Git than declaring it so. I've been watching CPython do this with the corner of one eye. We will have both bugs.jython.org and Git pull requests for a while ... essentially forever. There was some integration work (which we should steal, but that depends, I suspect, on upgrading the tracker) and conventions for how to refer to one from the other. It was tough at points because of disagreement on how it were best done, but we can just go along with their conclusion. And s/bpo/bjo/.

Jeff Allen

On 27/05/2017 01:12, Jim Baker wrote:
Agreed. It's time for putting this release candidate out! I'm also glad about the timing, because this mean Stefan has a great base to build this summer's work on JyNI. I believe it's technically RC1 still because the last RC was a soft release, but Frank knows those specifics.

I just ran the "yolk smoke test" from http://bugs.jython.org/issue2570 <http://bugs.jython.org/issue2570> one last time, just to make sure. Everything looks great!

After this we can look into:

1. Finally get jython.org <http://jython.org> revamped. I suggest the simplicity — and modern look — of GitHub pages, where we can host and then point jython.org <http://jython.org> accordingly.
2. Switch to the Gradle build that Darjus has been working on
3. Cut over to https://github.com/jython/jython with rewritten history that removes extlib jars for a subsequent release of 2.7.x, where x > 1 (maybe it's 12 for the next release, but we can decide later).

Lastly, I also felt it was important to highlight Stefan's contribution to helping finalize 2.7.1, as well as our appreciation to Google for supporting him this summer for the Google Summer of Code. First win for GSOC 2017 in other words. Duly noted as of https://hg.python.org/jython/rev/ab5434be88aa

- Jim



On May 26, 2017 7:24 PM, "Stefan Richthofer" <[hidden email] <mailto:[hidden email]>> wrote:

    > You can apply these updates to extlibs
    Done as of https://hg.python.org/jython/rev/f6b3ddbc1df8
    <https://hg.python.org/jython/rev/f6b3ddbc1df8>.
    From my point of view we can launch Jython 2.7.1-RC2 now.
    - no open PRs on github left
    - no release blockers left apparently except #2487
    - all updates done as far as possible (python std-lib will be next
    challenge on this front)
    So, I'd suggest everybody pushes last-minute work and Frank hits
    the release-button... :-)
    What do you think?
    Cheers!
    -Stefan

<snip>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7.1rc, to infinity and beyond!

Jim Baker-2
Updated README to state RC2, plus fixed the typo. Thanks for the feedback!

Agreed that getting on github will not be the most minor fix (!), but it will be worth the effort. I do like Mercurial, and very much appreciate the Hg team's help in moving Jython to hg.python.org from Subversion. Nonetheless, we found out in using Mercurial for the last 5 or so years for Jython development that it didn't match our development processes. It's both time to move on, and join CPython upstream in its dev processes.

On Sat, May 27, 2017 at 5:07 AM, Adam Burke <[hidden email]> wrote:
I know I'm a lurker and not an active dev, but I'd prefer the rc2 name as well, fwiw.

Cheers
Adam

On 27 May 2017 at 15:33, Jeff Allen <[hidden email]> wrote:
Excellent news! A lot has gone on between 2.7.0 and 2.7.1. it's good to find we've all feel "done"at the same time :)

Small typo in your front page: "many others to thanks".

I have a weak preference for calling it RC2 given there was change after RC1. I think RC1 still identifies a release, even if it was announced softly, and what we have now is different.

There's a bit more to cutting over to Git than declaring it so. I've been watching CPython do this with the corner of one eye. We will have both bugs.jython.org and Git pull requests for a while ... essentially forever. There was some integration work (which we should steal, but that depends, I suspect, on upgrading the tracker) and conventions for how to refer to one from the other. It was tough at points because of disagreement on how it were best done, but we can just go along with their conclusion. And s/bpo/bjo/.

Jeff Allen

On 27/05/2017 01:12, Jim Baker wrote:
Agreed. It's time for putting this release candidate out! I'm also glad about the timing, because this mean Stefan has a great base to build this summer's work on JyNI. I believe it's technically RC1 still because the last RC was a soft release, but Frank knows those specifics.

I just ran the "yolk smoke test" from http://bugs.jython.org/issue2570 <http://bugs.jython.org/issue2570> one last time, just to make sure. Everything looks great!

After this we can look into:

1. Finally get jython.org <http://jython.org> revamped. I suggest the simplicity — and modern look — of GitHub pages, where we can host and then point jython.org <http://jython.org> accordingly.
2. Switch to the Gradle build that Darjus has been working on
3. Cut over to https://github.com/jython/jython with rewritten history that removes extlib jars for a subsequent release of 2.7.x, where x > 1 (maybe it's 12 for the next release, but we can decide later).

Lastly, I also felt it was important to highlight Stefan's contribution to helping finalize 2.7.1, as well as our appreciation to Google for supporting him this summer for the Google Summer of Code. First win for GSOC 2017 in other words. Duly noted as of https://hg.python.org/jython/rev/ab5434be88aa

- Jim



On May 26, 2017 7:24 PM, "Stefan Richthofer" <[hidden email] <mailto:[hidden email]>> wrote:

    > You can apply these updates to extlibs
    Done as of https://hg.python.org/jython/rev/f6b3ddbc1df8
    <https://hg.python.org/jython/rev/f6b3ddbc1df8>.
    From my point of view we can launch Jython 2.7.1-RC2 now.
    - no open PRs on github left
    - no release blockers left apparently except #2487
    - all updates done as far as possible (python std-lib will be next
    challenge on this front)
    So, I'd suggest everybody pushes last-minute work and Frank hits
    the release-button... :-)
    What do you think?
    Cheers!
    -Stefan

<snip>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7.1rc, to infinity and beyond!

fwierzbicki@gmail.com
Great news, and amazing work everyone! I'll get the soft release together this weekend. If there are no troubles, I'll get the hard RC2 out next week.

On May 27, 2017 10:46, "Jim Baker" <[hidden email]> wrote:
Updated README to state RC2, plus fixed the typo. Thanks for the feedback!

Agreed that getting on github will not be the most minor fix (!), but it will be worth the effort. I do like Mercurial, and very much appreciate the Hg team's help in moving Jython to hg.python.org from Subversion. Nonetheless, we found out in using Mercurial for the last 5 or so years for Jython development that it didn't match our development processes. It's both time to move on, and join CPython upstream in its dev processes.

On Sat, May 27, 2017 at 5:07 AM, Adam Burke <[hidden email]> wrote:
I know I'm a lurker and not an active dev, but I'd prefer the rc2 name as well, fwiw.

Cheers
Adam

On 27 May 2017 at 15:33, Jeff Allen <[hidden email]> wrote:
Excellent news! A lot has gone on between 2.7.0 and 2.7.1. it's good to find we've all feel "done"at the same time :)

Small typo in your front page: "many others to thanks".

I have a weak preference for calling it RC2 given there was change after RC1. I think RC1 still identifies a release, even if it was announced softly, and what we have now is different.

There's a bit more to cutting over to Git than declaring it so. I've been watching CPython do this with the corner of one eye. We will have both bugs.jython.org and Git pull requests for a while ... essentially forever. There was some integration work (which we should steal, but that depends, I suspect, on upgrading the tracker) and conventions for how to refer to one from the other. It was tough at points because of disagreement on how it were best done, but we can just go along with their conclusion. And s/bpo/bjo/.

Jeff Allen

On 27/05/2017 01:12, Jim Baker wrote:
Agreed. It's time for putting this release candidate out! I'm also glad about the timing, because this mean Stefan has a great base to build this summer's work on JyNI. I believe it's technically RC1 still because the last RC was a soft release, but Frank knows those specifics.

I just ran the "yolk smoke test" from http://bugs.jython.org/issue2570 <http://bugs.jython.org/issue2570> one last time, just to make sure. Everything looks great!

After this we can look into:

1. Finally get jython.org <http://jython.org> revamped. I suggest the simplicity — and modern look — of GitHub pages, where we can host and then point jython.org <http://jython.org> accordingly.
2. Switch to the Gradle build that Darjus has been working on
3. Cut over to https://github.com/jython/jython with rewritten history that removes extlib jars for a subsequent release of 2.7.x, where x > 1 (maybe it's 12 for the next release, but we can decide later).

Lastly, I also felt it was important to highlight Stefan's contribution to helping finalize 2.7.1, as well as our appreciation to Google for supporting him this summer for the Google Summer of Code. First win for GSOC 2017 in other words. Duly noted as of https://hg.python.org/jython/rev/ab5434be88aa

- Jim



On May 26, 2017 7:24 PM, "Stefan Richthofer" <[hidden email] <mailto:[hidden email]>> wrote:

    > You can apply these updates to extlibs
    Done as of https://hg.python.org/jython/rev/f6b3ddbc1df8
    <https://hg.python.org/jython/rev/f6b3ddbc1df8>.
    From my point of view we can launch Jython 2.7.1-RC2 now.
    - no open PRs on github left
    - no release blockers left apparently except #2487
    - all updates done as far as possible (python std-lib will be next
    challenge on this front)
    So, I'd suggest everybody pushes last-minute work and Frank hits
    the release-button... :-)
    What do you think?
    Cheers!
    -Stefan

<snip>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7.1rc, to infinity and beyond!

Stefan Richthofer
> Agreed that getting on github will not be the most minor fix

It occurred to me that this change actually aligns with our focus shift to Jython 3. Maybe we can benefit from this by setting up the new workflow only for Jython 3. Then it would be kind of a reboot rather than a (potentially painful) migration. It would naturaly sort out Jython 3 stuff from Jython 2 stuff. (We could even consider to track Jython 3 issues on github and continue bjo just for Jython 2.) Think about it.
 
 
> I also felt it was important to highlight Stefan's contribution to helping finalize 2.7.1

It's a great honor for me to be mentioned for this. Thank you very much!
Looking at ACKNOWLEDGEMENTS I found that the file does not explicitly display who is actually core-developing Jython right now. Jeff, Jim, Darjus and Frank who are putting a lot of work into Jython (or did so in the last years) are mentioned randomly between all contributors, including persons with really minimal contributions (don't get me wrong - every contribution is very valuable!). While this is a very modest attitude I think the (active) core-dev team should be explicitly named somewhere at the beginning of the file, not lastly because users might need this info to assess who to ask. Also - maybe I overlooked it - it is nowhere stated that Frank is the project lead. This should be made clear IMO. In case we decided to add such a section I'd suggest to also mention James Mudd, at least for this release, because he spent significantly more work on Jython than the average contributor.
 
 
> I'll get the soft release together this weekend. If there are no troubles, I'll get the hard RC2 out next week.

Looking forward to it! Thanks a lot.
 

Best regards
 
-Stefan
 
 
 
Gesendet: Samstag, 27. Mai 2017 um 20:43 Uhr
Von: "[hidden email]" <[hidden email]>
An: "Jim Baker" <[hidden email]>
Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] 2.7.1rc, to infinity and beyond!
Great news, and amazing work everyone! I'll get the soft release together this weekend. If there are no troubles, I'll get the hard RC2 out next week.
 
On May 27, 2017 10:46, "Jim Baker" <[hidden email]> wrote:
Updated README to state RC2, plus fixed the typo. Thanks for the feedback!
 
Agreed that getting on github will not be the most minor fix (!), but it will be worth the effort. I do like Mercurial, and very much appreciate the Hg team's help in moving Jython to hg.python.org from Subversion. Nonetheless, we found out in using Mercurial for the last 5 or so years for Jython development that it didn't match our development processes. It's both time to move on, and join CPython upstream in its dev processes.
 
On Sat, May 27, 2017 at 5:07 AM, Adam Burke <[hidden email]> wrote:
I know I'm a lurker and not an active dev, but I'd prefer the rc2 name as well, fwiw.
 
Cheers
Adam
 
On 27 May 2017 at 15:33, Jeff Allen <[hidden email]> wrote:
Excellent news! A lot has gone on between 2.7.0 and 2.7.1. it's good to find we've all feel "done"at the same time :)

Small typo in your front page: "many others to thanks".

I have a weak preference for calling it RC2 given there was change after RC1. I think RC1 still identifies a release, even if it was announced softly, and what we have now is different.

There's a bit more to cutting over to Git than declaring it so. I've been watching CPython do this with the corner of one eye. We will have both bugs.jython.org and Git pull requests for a while ... essentially forever. There was some integration work (which we should steal, but that depends, I suspect, on upgrading the tracker) and conventions for how to refer to one from the other. It was tough at points because of disagreement on how it were best done, but we can just go along with their conclusion. And s/bpo/bjo/.

Jeff Allen

On 27/05/2017 01:12, Jim Baker wrote:
Agreed. It's time for putting this release candidate out! I'm also glad about the timing, because this mean Stefan has a great base to build this summer's work on JyNI. I believe it's technically RC1 still because the last RC was a soft release, but Frank knows those specifics.

I just ran the "yolk smoke test" from http://bugs.jython.org/issue2570 <http://bugs.jython.org/issue2570> one last time, just to make sure. Everything looks great!

After this we can look into:

1. Finally get jython.org <http://jython.org> revamped. I suggest the simplicity — and modern look — of GitHub pages, where we can host and then point jython.org <http://jython.org> accordingly.
2. Switch to the Gradle build that Darjus has been working on
3. Cut over to https://github.com/jython/jython with rewritten history that removes extlib jars for a subsequent release of 2.7.x, where x > 1 (maybe it's 12 for the next release, but we can decide later).

Lastly, I also felt it was important to highlight Stefan's contribution to helping finalize 2.7.1, as well as our appreciation to Google for supporting him this summer for the Google Summer of Code. First win for GSOC 2017 in other words. Duly noted as of https://hg.python.org/jython/rev/ab5434be88aa

- Jim



On May 26, 2017 7:24 PM, "Stefan Richthofer" <[hidden email] <mailto:[hidden email]>> wrote:

    > You can apply these updates to extlibs
    Done as of https://hg.python.org/jython/rev/f6b3ddbc1df8
    <https://hg.python.org/jython/rev/f6b3ddbc1df8>.
    From my point of view we can launch Jython 2.7.1-RC2 now.
    - no open PRs on github left
    - no release blockers left apparently except #2487
    - all updates done as far as possible (python std-lib will be next
    challenge on this front)
    So, I'd suggest everybody pushes last-minute work and Frank hits
    the release-button... :-)
    What do you think?
    Cheers!
    -Stefan
 
<snip>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
 
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ Jython-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7.1rc, to infinity and beyond!

James Mudd
Just a few comments from my point of view.

I think moving to a Github based workflow will help to attract more contributors to Jython. I just think more people are familiar with the workflow, so it's less effort to get involved, even minor things like having to sign up to bugs.jython.org might put people off. Having said that I really hope more people get involved. I have really enjoyed putting some work into Jython, and have got to investigate some interesting bugs which has been really fun. I think its a unique kind of project which is really interesting to work on, and all the other contributors seem to be really friendly and helpful. I hope to keep contributing in the future when time allows.

Also thanks to Stefan for the comments, and the great discussion on many of the bugs fixed over the last few months, as well as merging many of my suggested patches.

Looking forward to seeing the RC2, and hopefully soon after the final release.

James

On 28 May 2017 at 19:11, Stefan Richthofer <[hidden email]> wrote:
> Agreed that getting on github will not be the most minor fix

It occurred to me that this change actually aligns with our focus shift to Jython 3. Maybe we can benefit from this by setting up the new workflow only for Jython 3. Then it would be kind of a reboot rather than a (potentially painful) migration. It would naturaly sort out Jython 3 stuff from Jython 2 stuff. (We could even consider to track Jython 3 issues on github and continue bjo just for Jython 2.) Think about it.
 
 
> I also felt it was important to highlight Stefan's contribution to helping finalize 2.7.1

It's a great honor for me to be mentioned for this. Thank you very much!
Looking at ACKNOWLEDGEMENTS I found that the file does not explicitly display who is actually core-developing Jython right now. Jeff, Jim, Darjus and Frank who are putting a lot of work into Jython (or did so in the last years) are mentioned randomly between all contributors, including persons with really minimal contributions (don't get me wrong - every contribution is very valuable!). While this is a very modest attitude I think the (active) core-dev team should be explicitly named somewhere at the beginning of the file, not lastly because users might need this info to assess who to ask. Also - maybe I overlooked it - it is nowhere stated that Frank is the project lead. This should be made clear IMO. In case we decided to add such a section I'd suggest to also mention James Mudd, at least for this release, because he spent significantly more work on Jython than the average contributor.
 
 
> I'll get the soft release together this weekend. If there are no troubles, I'll get the hard RC2 out next week.

Looking forward to it! Thanks a lot.
 

Best regards
 
-Stefan
 
 
 
Gesendet: Samstag, 27. Mai 2017 um 20:43 Uhr
Von: "[hidden email]" <[hidden email]>
An: "Jim Baker" <[hidden email]>
Cc: "Jython Developers" <[hidden email]>
Betreff: Re: [Jython-dev] 2.7.1rc, to infinity and beyond!
Great news, and amazing work everyone! I'll get the soft release together this weekend. If there are no troubles, I'll get the hard RC2 out next week.
 
On May 27, 2017 10:46, "Jim Baker" <[hidden email]> wrote:
Updated README to state RC2, plus fixed the typo. Thanks for the feedback!
 
Agreed that getting on github will not be the most minor fix (!), but it will be worth the effort. I do like Mercurial, and very much appreciate the Hg team's help in moving Jython to hg.python.org from Subversion. Nonetheless, we found out in using Mercurial for the last 5 or so years for Jython development that it didn't match our development processes. It's both time to move on, and join CPython upstream in its dev processes.
 
On Sat, May 27, 2017 at 5:07 AM, Adam Burke <[hidden email]> wrote:
I know I'm a lurker and not an active dev, but I'd prefer the rc2 name as well, fwiw.
 
Cheers
Adam
 
On 27 May 2017 at 15:33, Jeff Allen <[hidden email]> wrote:
Excellent news! A lot has gone on between 2.7.0 and 2.7.1. it's good to find we've all feel "done"at the same time :)

Small typo in your front page: "many others to thanks".

I have a weak preference for calling it RC2 given there was change after RC1. I think RC1 still identifies a release, even if it was announced softly, and what we have now is different.

There's a bit more to cutting over to Git than declaring it so. I've been watching CPython do this with the corner of one eye. We will have both bugs.jython.org and Git pull requests for a while ... essentially forever. There was some integration work (which we should steal, but that depends, I suspect, on upgrading the tracker) and conventions for how to refer to one from the other. It was tough at points because of disagreement on how it were best done, but we can just go along with their conclusion. And s/bpo/bjo/.

Jeff Allen

On 27/05/2017 01:12, Jim Baker wrote:
Agreed. It's time for putting this release candidate out! I'm also glad about the timing, because this mean Stefan has a great base to build this summer's work on JyNI. I believe it's technically RC1 still because the last RC was a soft release, but Frank knows those specifics.

I just ran the "yolk smoke test" from http://bugs.jython.org/issue2570 <http://bugs.jython.org/issue2570> one last time, just to make sure. Everything looks great!

After this we can look into:

1. Finally get jython.org <http://jython.org> revamped. I suggest the simplicity — and modern look — of GitHub pages, where we can host and then point jython.org <http://jython.org> accordingly.
2. Switch to the Gradle build that Darjus has been working on
3. Cut over to https://github.com/jython/jython with rewritten history that removes extlib jars for a subsequent release of 2.7.x, where x > 1 (maybe it's 12 for the next release, but we can decide later).

Lastly, I also felt it was important to highlight Stefan's contribution to helping finalize 2.7.1, as well as our appreciation to Google for supporting him this summer for the Google Summer of Code. First win for GSOC 2017 in other words. Duly noted as of https://hg.python.org/jython/rev/ab5434be88aa

- Jim



On May 26, 2017 7:24 PM, "Stefan Richthofer" <[hidden email] <mailto:[hidden email]>> wrote:

    > You can apply these updates to extlibs
    Done as of https://hg.python.org/jython/rev/f6b3ddbc1df8
    <https://hg.python.org/jython/rev/f6b3ddbc1df8>.
    From my point of view we can launch Jython 2.7.1-RC2 now.
    - no open PRs on github left
    - no release blockers left apparently except #2487
    - all updates done as far as possible (python std-lib will be next
    challenge on this front)
    So, I'd suggest everybody pushes last-minute work and Frank hits
    the release-button... :-)
    What do you think?
    Cheers!
    -Stefan
 
<snip>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
 
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ Jython-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/jython-dev

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
Reply | Threaded
Open this post in threaded view
|

Re: 2.7.1rc, to infinity and beyond!

Jeff Allen-2
+1 on Stefan's suggestion that we simply start as we mean to go on with
Jython 3 on GitHub. We still must choose a workflow and make it known.
This might be a change of practice for those of us with direct commit
rights, away from commit-then-review, to something based on PRs. I was
always a bit surprised we did not have such a two-step process with
Mercurial.

Concerning identifying the value of individuals' contributions, I think
we enter a minefield. It seems to be the Python way that we're all just
names in a big flat acknowledgements file, however large or small our
contribution. I saw this principle enunciated by Guido on python-dev.
(Sorry, can't find it now.) Oh, now I look, it's loosely what the ACKS
file itself says.

I think it more practical to talk about what trust the project accords
someone, which brings us back to workflow. On CPython there's an
identified set of core developers who have the right (and are relied
upon) to review others' contributions and commit them to the project
repository -- being trusted to know their own competence. That is worth
being clearer about for Jython, especially if someone has commit rights
in practice but we don't expect them to review PRs/patches. On GitHub,
some of us are members and others owners, but I don't know what is
intended by that.

There was some debate in CPython about the new workflow, whether code
devs could review and accept their own work. I think there should
normally be at least the opportunity for peer review if work is a large
change ... something like I did for the 2.7.1 changes to the buffer
interface and UTF-8 fix.

In the unique case of the project lead, I believe Frank's status is a
PSF appointment. I have seen that in documentation somewhere, but why
not more prominently?

Jeff Allen

On 28/05/2017 21:45, James Mudd wrote:

> Just a few comments from my point of view.
>
> I think moving to a Github based workflow will help to attract more
> contributors to Jython. I just think more people are familiar with the
> workflow, so it's less effort to get involved, even minor things like
> having to sign up to bugs.jython.org <http://bugs.jython.org> might
> put people off. Having said that I really hope more people get
> involved. I have really enjoyed putting some work into Jython, and
> have got to investigate some interesting bugs which has been really
> fun. I think its a unique kind of project which is really interesting
> to work on, and all the other contributors seem to be really friendly
> and helpful. I hope to keep contributing in the future when time allows.
>
> Also thanks to Stefan for the comments, and the great discussion on
> many of the bugs fixed over the last few months, as well as merging
> many of my suggested patches.
>
> Looking forward to seeing the RC2, and hopefully soon after the final
> release.
>
> James
>
> On 28 May 2017 at 19:11, Stefan Richthofer <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     > Agreed that getting on github will not be the most minor fix
>
>     It occurred to me that this change actually aligns with our focus
>     shift to Jython 3. Maybe we can benefit from this by setting up
>     the new workflow only for Jython 3. Then it would be kind of a
>     reboot rather than a (potentially painful) migration. It would
>     naturaly sort out Jython 3 stuff from Jython 2 stuff. (We could
>     even consider to track Jython 3 issues on github and continue bjo
>     just for Jython 2.) Think about it.
>     > I also felt it was important to highlight Stefan's contribution to helping finalize 2.7.1
>
>     It's a great honor for me to be mentioned for this. Thank you very
>     much!
>     Looking at ACKNOWLEDGEMENTS I found that the file does not
>     explicitly display who is actually core-developing Jython right
>     now. Jeff, Jim, Darjus and Frank who are putting a lot of work
>     into Jython (or did so in the last years) are mentioned randomly
>     between all contributors, including persons with really minimal
>     contributions (don't get me wrong - every contribution is very
>     valuable!). While this is a very modest attitude I think the
>     (active) core-dev team should be explicitly named somewhere at the
>     beginning of the file, not lastly because users might need this
>     info to assess who to ask. Also - maybe I overlooked it - it is
>     nowhere stated that Frank is the project lead. This should be made
>     clear IMO. In case we decided to add such a section I'd suggest to
>     also mention James Mudd, at least for this release, because he
>     spent significantly more work on Jython than the average contributor.
>     > I'll get the soft release together this weekend. If there are no troubles, I'll get the hard RC2 out next
>     week.
>
>     Looking forward to it! Thanks a lot.
>
>     Best regards
>     -Stefan
>     *Gesendet:* Samstag, 27. Mai 2017 um 20:43 Uhr
>     *Von:* "[hidden email] <mailto:[hidden email]>"
>     <[hidden email] <mailto:[hidden email]>>
>     *An:* "Jim Baker" <[hidden email] <mailto:[hidden email]>>
>     *Cc:* "Jython Developers" <[hidden email]
>     <mailto:[hidden email]>>
>     *Betreff:* Re: [Jython-dev] 2.7.1rc, to infinity and beyond!
>     Great news, and amazing work everyone! I'll get the soft release
>     together this weekend. If there are no troubles, I'll get the hard
>     RC2 out next week.
>     On May 27, 2017 10:46, "Jim Baker" <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         Updated README to state RC2, plus fixed the typo. Thanks for
>         the feedback!
>         Agreed that getting on github will not be the most minor fix
>         (!), but it will be worth the effort. I do like Mercurial, and
>         very much appreciate the Hg team's help in moving Jython to
>         hg.python.org <http://hg.python.org> from Subversion.
>         Nonetheless, we found out in using Mercurial for the last 5 or
>         so years for Jython development that it didn't match our
>         development processes. It's both time to move on, and join
>         CPython upstream in its dev processes.
>         On Sat, May 27, 2017 at 5:07 AM, Adam Burke
>         <[hidden email] <mailto:[hidden email]>> wrote:
>
>             I know I'm a lurker and not an active dev, but I'd prefer
>             the rc2 name as well, fwiw.
>             Cheers
>             Adam
>             On 27 May 2017 at 15:33, Jeff Allen <[hidden email]
>             <mailto:[hidden email]>> wrote:
>
>                 Excellent news! A lot has gone on between 2.7.0 and
>                 2.7.1. it's good to find we've all feel "done"at the
>                 same time :)
>
>                 Small typo in your front page: "many others to thanks".
>
>                 I have a weak preference for calling it RC2 given
>                 there was change after RC1. I think RC1 still
>                 identifies a release, even if it was announced softly,
>                 and what we have now is different.
>
>                 There's a bit more to cutting over to Git than
>                 declaring it so. I've been watching CPython do this
>                 with the corner of one eye. We will have both
>                 bugs.jython.org <http://bugs.jython.org> and Git pull
>                 requests for a while ... essentially forever. There
>                 was some integration work (which we should steal, but
>                 that depends, I suspect, on upgrading the tracker) and
>                 conventions for how to refer to one from the other. It
>                 was tough at points because of disagreement on how it
>                 were best done, but we can just go along with their
>                 conclusion. And s/bpo/bjo/.
>
>                 Jeff Allen
>
>                 On 27/05/2017 01:12, Jim Baker wrote:
>
>                     Agreed. It's time for putting this release
>                     candidate out! I'm also glad about the timing,
>                     because this mean Stefan has a great base to build
>                     this summer's work on JyNI. I believe it's
>                     technically RC1 still because the last RC was a
>                     soft release, but Frank knows those specifics.
>
>                     I just ran the "yolk smoke test" from
>                     http://bugs.jython.org/issue2570
>                     <http://bugs.jython.org/issue2570>
>                     <http://bugs.jython.org/issue2570
>                     <http://bugs.jython.org/issue2570>> one last time,
>                     just to make sure. Everything looks great!
>
>                     After this we can look into:
>
>                     1. Finally get jython.org <http://jython.org>
>                     <http://jython.org> revamped. I suggest the
>                     simplicity — and modern look — of GitHub pages,
>                     where we can host and then point jython.org
>                     <http://jython.org> <http://jython.org> accordingly.
>                     2. Switch to the Gradle build that Darjus has been
>                     working on
>                     3. Cut over to https://github.com/jython/jython
>                     <https://github.com/jython/jython> with rewritten
>                     history that removes extlib jars for a subsequent
>                     release of 2.7.x, where x > 1 (maybe it's 12 for
>                     the next release, but we can decide later).
>
>                     Lastly, I also felt it was important to highlight
>                     Stefan's contribution to helping finalize 2.7.1,
>                     as well as our appreciation to Google for
>                     supporting him this summer for the Google Summer
>                     of Code. First win for GSOC 2017 in other words.
>                     Duly noted as of
>                     https://hg.python.org/jython/rev/ab5434be88aa
>                     <https://hg.python.org/jython/rev/ab5434be88aa>
>
>                     - Jim
>
>
>
>                     On May 26, 2017 7:24 PM, "Stefan Richthofer"
>                     <[hidden email]
>                     <mailto:[hidden email]>
>                     <mailto:[hidden email]
>                     <mailto:[hidden email]>>> wrote:
>
>                         > You can apply these updates to extlibs
>                         Done as of
>                     https://hg.python.org/jython/rev/f6b3ddbc1df8
>                     <https://hg.python.org/jython/rev/f6b3ddbc1df8>
>                         <https://hg.python.org/jython/rev/f6b3ddbc1df8
>                     <https://hg.python.org/jython/rev/f6b3ddbc1df8>>.
>                         From my point of view we can launch Jython
>                     2.7.1-RC2 now.
>                         - no open PRs on github left
>                         - no release blockers left apparently except #2487
>                         - all updates done as far as possible (python
>                     std-lib will be next
>                         challenge on this front)
>                         So, I'd suggest everybody pushes last-minute
>                     work and Frank hits
>                         the release-button... :-)
>                         What do you think?
>                         Cheers!
>                         -Stefan
>
>                 <snip>
>
>                 ------------------------------------------------------------------------------
>                 Check out the vibrant tech community on one of the
>                 world's most
>                 engaging tech sites, Slashdot.org!
>                 http://sdm.link/slashdot
>                 _______________________________________________
>                 Jython-dev mailing list
>                 [hidden email]
>                 <mailto:[hidden email]>
>                 https://lists.sourceforge.net/lists/listinfo/jython-dev
>                 <https://lists.sourceforge.net/lists/listinfo/jython-dev>
>
>
>             ------------------------------------------------------------------------------
>             Check out the vibrant tech community on one of the world's
>             most
>             engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>             _______________________________________________
>             Jython-dev mailing list
>             [hidden email]
>             <mailto:[hidden email]>
>             https://lists.sourceforge.net/lists/listinfo/jython-dev
>             <https://lists.sourceforge.net/lists/listinfo/jython-dev>
>
>
>         ------------------------------------------------------------------------------
>         Check out the vibrant tech community on one of the world's most
>         engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>         _______________________________________________
>         Jython-dev mailing list
>         [hidden email]
>         <mailto:[hidden email]>
>         https://lists.sourceforge.net/lists/listinfo/jython-dev
>         <https://lists.sourceforge.net/lists/listinfo/jython-dev>
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org!
>     http://sdm.link/slashdot_______________________________________________
>     <http://sdm.link/slashdot_______________________________________________>
>     Jython-dev mailing list [hidden email]
>     <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/jython-dev
>     <https://lists.sourceforge.net/lists/listinfo/jython-dev>
>
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     Jython-dev mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/jython-dev
>     <https://lists.sourceforge.net/lists/listinfo/jython-dev>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Jython-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jython-dev


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jython-dev
12