Menu
▾
▴
Re: [Jython-dev] Updating extlibs
|
From: Jim B. <jim...@py...> - 2017-05-27 00:13:07
|
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" <Ste...@gm...> wrote: > > You can apply these updates to extlibs > Done as of 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 > > > *Gesendet:* Freitag, 26. Mai 2017 um 20:16 Uhr > *Von:* "Jim Baker" <jim...@py...> > *An:* "Stefan Richthofer" <Ste...@gm...> > *Cc:* "Jython Developers" <jyt...@li...> > *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/jytho > n-extlibs/dist/Lib/test/test_socket.py", line 186, in clientRun > [exec] self.clientSetUp() > [exec] File "/Users/jbaker/jythondev/jytho > n-extlibs/dist/Lib/test/test_socket.py", line 246, in clientSetUp > [exec] self.cli.connect((self.HOST, self.PORT)) > [exec] File "/Users/jbaker/jythondev/jytho > n-extlibs/dist/Lib/_socket.py", line 1441, in meth > [exec] return getattr(self._sock,name)(*args) > [exec] File "/Users/jbaker/jythondev/jytho > n-extlibs/dist/Lib/_socket.py", line 935, in connect > [exec] self._connect(addr) > [exec] File "/Users/jbaker/jythondev/jytho > n-extlibs/dist/Lib/_socket.py", line 911, in _connect > [exec] self._handle_channel_future(self.connect_future, > "connect") > [exec] File "/Users/jbaker/jythondev/jytho > n-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 < > Ste...@gm...> wrote: >> >> Did someone test this on OSX? (reminder: https://github.com/Stewori/jyt >> hon) >> 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" <Ste...@gm...> >> *An:* "Jim Baker" <jim...@py...> >> >> *Cc:* "Jython Developers" <jyt...@li...> >> *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" <jim...@py...> >> *An:* "Stefan Richthofer" <Ste...@gm...> >> *Cc:* "Jython Developers" <jyt...@li...> >> *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 < >> Ste...@gm...> wrote: >>> >>> I uploaded the mentioned updates to >>> https://github.com/Stewori/jython. >>> See detailed changes at >>> https://github.com/Stewori/jython/commit/ee2b1263306f779bf8e >>> 9499afc6d02267648ac36 >>> >>> 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" <Ste...@gm...> >>> > An: "Jython Developers" <jyt...@li...> >>> > 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 >>> Jyt...@li... >>> 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 >> Jyt...@li... 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 >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> > > |
