From: Mark R. <wi...@gm...> - 2014-03-18 20:26:27
|
Hey all, I've been looking around for some information about what the status of Jython 2.7 is, and the timeline for it coming out of beta. -Mark |
From: Pradeep B. <Pra...@fi...> - 2015-03-17 16:18:27
|
Hi, When can we expect a production ready build for Jython 2.7? Thanks, Pradeep V.B. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately. |
From: Jim B. <jim...@py...> - 2015-03-18 04:20:05
|
I expect this week we will have a soft release of the release candidate. I have postponed or fixed the remaining urgent bugs that require code development. Now the only remaining bug is packaging, http://bugs.jython.org/issue2282, which requires a change in the build.xml. However, if it proves to be too hard it will also get postponed, since a workaround does exist AND we are going to update packaging in a future release, namely support of Maven builds with http://bugs.jython.org/issue2182 On Tue, Mar 17, 2015 at 10:18 AM, Pradeep Badiger <Pra...@fi...> wrote: > Hi, > > > > When can we expect a production ready build for Jython 2.7? > > > > Thanks, > > Pradeep V.B. > > > > This email and any files transmitted with it are confidential, proprietary > and intended solely for the individual or entity to whom they are > addressed. If you have received this email in error please delete it > immediately. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > > -- - Jim jim.baker@{colorado.edu|python.org|rackspace.com|zyasoft.com} twitter.com/jimbaker github.com/jimbaker bitbucket.com/jimbaker |
From: Jim B. <jb...@zy...> - 2014-03-19 02:32:57
|
Mark, That's a great question! Currently in my own Jython development work I'm focused on the *blocker for beta 2*: pip support. Jython 2.7 must have support for the standard tools in the Python ecosystem. Of these, pip - and related virtualenv and easy_install - are absolutely critical. The pip tool in turn requires the requests package, which in turn requires support for nonblocking SSL. It's been much more involved than we hoped, but this branch is currently converging on such support: https://bitbucket.org/jimbaker/jython-socket-reboot; currently at least 2/3 of the tests in test_socket pass, beyond the fact that it supports SSL (including Start TLS) . Remaining work includes support for pseudo socket options and similar relatively minor bits & pieces. (It's at least 2/3 of ~150 tests, but more difficult to characterize than usual since most tests use threading and perhaps consequently if there's any problem, they simply freeze the overall test.) I'm hoping that this can be substantially complete by the end of the week; I certainly cannot wait until this happens because perhaps the last thing I wanted to work on when I resumed active development on Jython was SSL, but here I am doing it ;) There is of course other important work going on, as seen in the commits and a number of outstanding pull requests, but I believe our project consensus is that this is the one blocker we have for beta 2. Once this socket-reboot work is resolved, I believe we will want to have one more beta, focused on performance/bug fixes. This will include the following support: - Bug triage, especially Windows bugs - Regex improvements in the underlying SRE, likely using the memoization proposed by Indra Talip https://bitbucket.org/indratalip/jython - Use Jackson for our implementation of the json module (Some of these could make beta 2, but they will not block it.) Related to this, a number of us have started a separate project, jythontools (https://github.com/jythontools/), to capture integration points that in the past we would have directly put into Jython itself, such as Clamp. Keeping such work in the jythontools project helps decouple this work. I can understand this is frustrating for our users who want to have firm dates. The problem is that Jython *2.7.0* necessarily uses a feature-based schedule, vs a time-based schedule (as seen in CPython, for example). Jython focuses on compatibility with the Python language, as defined by the CPython reference implementation; and usability as part of the overall Python ecosystem, as now defined by PyPI and tooling like pip. Subsequent releases of 2.7.1, etc., can instead use a time-based schedule, as we move to working on performance, better Java integration, and of course bug fixes. I certainly cannot wait until we reach that milestone! - Jim On Tue, Mar 18, 2014 at 2:26 PM, Mark Roberts <wi...@gm...> wrote: > Hey all, > > I've been looking around for some information about what the status of > Jython 2.7 is, and the timeline for it coming out of beta. > > -Mark > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > > |
From: Jeff A. <ja...@fa...> - 2014-03-22 17:26:43
|
Reasoning about this a little, unless there are fixed expectations for the quality of each successive beta release, we should base them largely on the passage of time. By "expectations" I mean you could decide e.g. that the number of test suite fails, guilty skips, or accepted bugs has to be half what it was last time, or matches some target. But I don't advocate this. A red buildbot ought to be a blocker, although that's simply a matter of skipping enough tests. Apart from that, I advocate time-based betas to engage a community not prepared to build from source. It's nice to get a feature you care about in the next beta, but it's more important to maintain the habit of production. I believe I could argue that a period of steady bug-fixing makes a better prelude to a release than the first appearance of a shiny feature. We believe we have reached "beta quality", hence b1 exists. Change is /almost/ always done without regressions and we have added important features and fixes. Therefore we must be maintaining at least beta quality and must eventually cross the threshold into release candidate territory. I'm not sure when that release candidate threshold might be reached. I'm not aware of any neglected features (like buffer was). MBCS maybe. io is still messy. I don't think Windows is specially an issue now, as we've nearly equalised the number of test failures between that and Linux. (Sorry, I think I added one to Linux.) I'm largely content to be guided by others on the project about what's good enough to release, but Jim's analysis strikes me as optimistic. We have quite a lot of fails and skips in the regression tests, and sometimes they represent knotty issues. On the plus side, when we fix a knotty one, we get rid of several skips at once. This is where my energy goes at the moment. Good fun if anyone wants to join in. Jeff On 19/03/2014 02:32, Jim Baker wrote: > Mark, > > That's a great question! > > Currently in my own Jython development work I'm focused on the > *blocker for beta 2*: pip support. Jython 2.7 must have support for > the standard tools in the Python ecosystem. Of these, pip - and > related virtualenv and easy_install - are absolutely critical. The pip > tool in turn requires the requests package, which in turn requires > support for nonblocking SSL. > > It's been much more involved than we hoped, but this branch is > currently converging on such support: > https://bitbucket.org/jimbaker/jython-socket-reboot; currently at > least 2/3 of the tests in test_socket pass, beyond the fact that it > supports SSL (including Start TLS) . Remaining work includes support > for pseudo socket options and similar relatively minor bits & pieces. > (It's at least 2/3 of ~150 tests, but more difficult to characterize > than usual since most tests use threading and perhaps consequently if > there's any problem, they simply freeze the overall test.) I'm hoping > that this can be substantially complete by the end of the week; I > certainly cannot wait until this happens because perhaps the last > thing I wanted to work on when I resumed active development on Jython > was SSL, but here I am doing it ;) > > There is of course other important work going on, as seen in the > commits and a number of outstanding pull requests, but I believe our > project consensus is that this is the one blocker we have for beta 2. > > Once this socket-reboot work is resolved, I believe we will want to > have one more beta, focused on performance/bug fixes. This will > include the following support: > > * Bug triage, especially Windows bugs > * Regex improvements in the underlying SRE, likely using the > memoization proposed by Indra Talip > https://bitbucket.org/indratalip/jython > * Use Jackson for our implementation of the json module > > (Some of these could make beta 2, but they will not block it.) > > Related to this, a number of us have started a separate project, > jythontools (https://github.com/jythontools/), to capture integration > points that in the past we would have directly put into Jython itself, > such as Clamp. Keeping such work in the jythontools project helps > decouple this work. > > I can understand this is frustrating for our users who want to have > firm dates. The problem is that Jython *2.7.0* necessarily uses a > feature-based schedule, vs a time-based schedule (as seen in CPython, > for example). Jython focuses on compatibility with the Python > language, as defined by the CPython reference implementation; and > usability as part of the overall Python ecosystem, as now defined by > PyPI and tooling like pip. > > Subsequent releases of 2.7.1, etc., can instead use a time-based > schedule, as we move to working on performance, better Java > integration, and of course bug fixes. I certainly cannot wait until we > reach that milestone! > > - Jim > > > > > On Tue, Mar 18, 2014 at 2:26 PM, Mark Roberts <wi...@gm... > <mailto:wi...@gm...>> wrote: > > Hey all, > > I've been looking around for some information about what the > status of Jython 2.7 is, and the timeline for it coming out of beta. > > -Mark > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases > and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > <mailto:Jyt...@li...> > https://lists.sourceforge.net/lists/listinfo/jython-dev > > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > > > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
From: Jim B. <jb...@zy...> - 2014-03-23 03:42:11
|
I'm glad to have this discussion! More inline: On Sat, Mar 22, 2014 at 11:26 AM, Jeff Allen <ja...@fa...> wrote: > Reasoning about this a little, unless there are fixed expectations for > the quality of each successive beta release, we should base them largely on > the passage of time. By "expectations" I mean you could decide e.g. that > the number of test suite fails, guilty skips, or accepted bugs has to be > half what it was last time, or matches some target. But I don't advocate > this. > > A red buildbot ought to be a blocker, although that's simply a matter of > skipping enough tests. Apart from that, I advocate time-based betas to > engage a community not prepared to build from source. It's nice to get a > feature you care about in the next beta, but it's more important to > maintain the habit of production. I believe I could argue that a period of > steady bug-fixing makes a better prelude to a release than the first > appearance of a shiny feature. > Good points, especially with respect to the following: 1. The significant console fixes you've done, which directly supports a representative user (as we saw in another email thread). The vast preponderance of our users likely do not build from source is another important factor. 2. We are doing feature-based development, converging on a 2.7.0 as set by the CPython reference. But you're right, we should complement this with regular releases. 3. We will get more user feedback as they see and use betas. So +1 on an immediate beta release. Any others? Frank, what do you think? > We believe we have reached "beta quality", hence b1 exists. Change is > *almost* always done without regressions and we have added important > features and fixes. Therefore we must be maintaining at least beta quality > and must eventually cross the threshold into release candidate territory. > > I'm not sure when that release candidate threshold might be reached. I'm > not aware of any neglected features (like buffer was). MBCS maybe. io is > still messy. I don't think Windows is specially an issue now, as we've > nearly equalised the number of test failures between that and Linux. > (Sorry, I think I added one to Linux.) > > I'm largely content to be guided by others on the project about what's > good enough to release, but Jim's analysis strikes me as optimistic. We > have quite a lot of fails and skips in the regression tests, and sometimes > they represent knotty issues. On the plus side, when we fix a knotty one, > we get rid of several skips at once. This is where my energy goes at the > moment. Good fun if anyone wants to join in. > Absolutely agreed on the satisfaction of seeing those bugs get fixed! Let's recall the reason for the socket-reboot work, and why I see it as important enough to be a blocker in our release cycle. Jython 2.7 needs to be a full participant of the Python ecosystem, especially since this is the case with 2.5. I was quite reluctant to put this time into fixing ssl, because I was not then an expert in low-level networking APIs, certainly on the C side. But socket-reboot needed to be done, and I'm glad it is getting close to be completed. In particular, it's getting quite close for test_socket passing, and that's why I'm now rather optimistic about it. Perhaps the last feature to be implemented for socket itself is socket.dup, which is also important for actually using socket.makefile. The socket.dup method is just one more example of what is required to support socket closing semantics. So perhaps not unexpected, much of the work I have been doing in the last week has been about the closing of sockets overall, which the test_socket test suites have been good at identifying any issues in. Suffice to say, sockets can/must be closed for many reasons! - Jim |
From: <fwi...@gm...> - 2014-03-23 17:09:45
|
So +1 on an immediate beta release. Any others? Frank, what do you think? > Let's see what I can do - I think I have everything in place... -Frank |
From: <fwi...@gm...> - 2014-03-23 17:16:04
|
On Sun, Mar 23, 2014 at 10:09 AM, fwi...@gm... < fwi...@gm...> wrote: > > > So +1 on an immediate beta release. Any others? Frank, what do you think? >> > Let's see what I can do - I think I have everything in place... > No promises on what "immediate" means exactly - it turns out I do not have everything in place after all - but I will give a status update soonish. -Frank |
From: Josh J. <jun...@gm...> - 2014-03-23 22:47:25
|
+1! Josh Juneau > On Mar 23, 2014, at 12:15 PM, "fwi...@gm..." <fwi...@gm...> wrote: > > > > >> On Sun, Mar 23, 2014 at 10:09 AM, fwi...@gm... <fwi...@gm...> wrote: >> >> >>> So +1 on an immediate beta release. Any others? Frank, what do you think? >> >> Let's see what I can do - I think I have everything in place... > No promises on what "immediate" means exactly - it turns out I do not have everything in place after all - but I will give a status update soonish. > > -Frank > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
From: <fwi...@gm...> - 2014-03-24 16:17:53
|
Progress report: JDK7's verifier is tripping me up around the way we compile exception handlers - I remember that Shashank Bharadwaj did some work on this but it was never merged in. I'm torn on whether to go back to compiling with JDK6 this time around or finding a workaround. The trouble looks like this: Exception in thread "main" java.lang.VerifyError: Stack map does not match the one at exception handler 63 Exception Details: Location: org/python/core/PyObject.proxyInit()V @63: astore Reason: Type top (current frame, locals[3]) is not assignable to 'org/python/core/PyObject' (stack map, locals[3]) Current Frame: bci: @52 flags: { } locals: { 'org/python/core/PyObject', 'java/lang/Class', 'org/python/core/PyObject' } stack: { 'java/lang/InstantiationException' } Stackmap Frame: bci: @63 flags: { } locals: { 'org/python/core/PyObject', 'java/lang/Class', top, 'org/python/core/PyObject' } stack: { 'java/lang/InstantiationException' } Bytecode: 0000000: 2ab6 00be b600 d64c 2ab4 00d8 c700 072b 0000010: c700 04b1 12dc 2bb6 00e0 9a00 0912 e2b8 0000020: 00e5 bfb2 00eb b600 f1c0 0002 4db2 00eb 0000030: 2ab6 00f5 2bb6 00f8 c000 dc4e a700 4a3a 0000040: 042b b600 fb3a 0512 fd3a 0619 05c6 0022 0000050: bb00 ff59 b701 0019 06b6 0104 1301 06b6 0000060: 0104 1905 b601 09b6 0104 b601 0c3a 0619 0000070: 06b8 006c bf3a 0413 010e b800 6cbf 3a04 0000080: 1904 b801 12bf b200 eb2c b600 f5a7 000f 0000090: 3a07 b200 eb2c b600 f519 07bf 2ab4 00d8 00000a0: c600 122a b400 d82d a500 0a13 0116 b800 00000b0: 6cbf 2db9 0119 0100 3a04 1904 c600 1019 00000c0: 042a a500 0a13 011b b800 6cbf 2a2d b500 00000d0: d8b1 Exception Handler Table: bci [52, 60] => handler: 63 bci [52, 60] => handler: 117 bci [52, 60] => handler: 126 bci [52, 134] => handler: 144 bci [144, 146] => handler: 144 Stackmap Table: append_frame(@19,Object[#218]) same_frame(@20) same_frame(@35) full_frame(@63,{Object[#2],Object[#218],Top,Object[#2]},{Object[#207]}) append_frame(@111,Object[#207],Object[#218],Object[#156]) full_frame(@117,{Object[#2],Object[#218],Top,Object[#2]},{Object[#209]}) same_locals_1_stack_item_frame(@126,Object[#211]) full_frame(@134,{Object[#2],Object[#218],Object[#220],Object[#2]},{}) full_frame(@144,{Object[#2],Object[#218],Top,Object[#2]},{Object[#276]}) full_frame(@156,{Object[#2],Object[#218],Object[#220],Object[#2]},{}) same_frame(@178) append_frame(@204,Object[#2]) at org.python.util.jython.run(jython.java:213) at org.python.util.jython.main(jython.java:145) |
From: Jeff A. <ja...@fa...> - 2014-03-24 19:44:17
|
That's not a display that means a huge lot to me. jython.java:213 is a first call to PySystemState.getBaseProperties(), so I guess the error is while loading PySystemState? I ran "ant javatest regrtest" on Windows 7 and on Linux before committing the 1.6 to 1.7 change, with only the usual failures. (Slightly fewer on 1.7.) Is this just running Jython at the prompt? Say if there's something you'd like me to try on my platforms. Jeff On 24/03/2014 16:17, fwi...@gm... wrote: > Progress report: JDK7's verifier is tripping me up around the way we > compile exception handlers - I remember that Shashank Bharadwaj did > some work on this but it was never merged in. I'm torn on whether to > go back to compiling with JDK6 this time around or finding a workaround. > > The trouble looks like this: > > Exception in thread "main" java.lang.VerifyError: Stack map does not > match the one at exception handler 63 > Exception Details: > Location: > org/python/core/PyObject.proxyInit()V @63: astore > Reason: > Type top (current frame, locals[3]) is not assignable to > 'org/python/core/PyObject' (stack map, locals[3]) > Current Frame: > bci: @52 > flags: { } > locals: { 'org/python/core/PyObject', 'java/lang/Class', > 'org/python/core/PyObject' } > stack: { 'java/lang/InstantiationException' } > Stackmap Frame: > bci: @63 > flags: { } > locals: { 'org/python/core/PyObject', 'java/lang/Class', top, > 'org/python/core/PyObject' } > stack: { 'java/lang/InstantiationException' } > Bytecode: > 0000000: 2ab6 00be b600 d64c 2ab4 00d8 c700 072b > 0000010: c700 04b1 12dc 2bb6 00e0 9a00 0912 e2b8 > 0000020: 00e5 bfb2 00eb b600 f1c0 0002 4db2 00eb > 0000030: 2ab6 00f5 2bb6 00f8 c000 dc4e a700 4a3a > 0000040: 042b b600 fb3a 0512 fd3a 0619 05c6 0022 > 0000050: bb00 ff59 b701 0019 06b6 0104 1301 06b6 > 0000060: 0104 1905 b601 09b6 0104 b601 0c3a 0619 > 0000070: 06b8 006c bf3a 0413 010e b800 6cbf 3a04 > 0000080: 1904 b801 12bf b200 eb2c b600 f5a7 000f > 0000090: 3a07 b200 eb2c b600 f519 07bf 2ab4 00d8 > 00000a0: c600 122a b400 d82d a500 0a13 0116 b800 > 00000b0: 6cbf 2db9 0119 0100 3a04 1904 c600 1019 > 00000c0: 042a a500 0a13 011b b800 6cbf 2a2d b500 > 00000d0: d8b1 > Exception Handler Table: > bci [52, 60] => handler: 63 > bci [52, 60] => handler: 117 > bci [52, 60] => handler: 126 > bci [52, 134] => handler: 144 > bci [144, 146] => handler: 144 > Stackmap Table: > append_frame(@19,Object[#218]) > same_frame(@20) > same_frame(@35) > full_frame(@63,{Object[#2],Object[#218],Top,Object[#2]},{Object[#207]}) > append_frame(@111,Object[#207],Object[#218],Object[#156]) > full_frame(@117,{Object[#2],Object[#218],Top,Object[#2]},{Object[#209]}) > same_locals_1_stack_item_frame(@126,Object[#211]) > full_frame(@134,{Object[#2],Object[#218],Object[#220],Object[#2]},{}) > full_frame(@144,{Object[#2],Object[#218],Top,Object[#2]},{Object[#276]}) > full_frame(@156,{Object[#2],Object[#218],Object[#220],Object[#2]},{}) > same_frame(@178) > append_frame(@204,Object[#2]) > > at org.python.util.jython.run(jython.java:213) > at org.python.util.jython.main(jython.java:145) > > |
From: <fwi...@gm...> - 2014-03-24 21:07:01
|
On Mon, Mar 24, 2014 at 12:43 PM, Jeff Allen <ja...@fa...> wrote: > That's not a display that means a huge lot to me. jython.java:213 is a > first call to PySystemState.getBaseProperties(), so I guess the error is > while loading PySystemState? > > I ran "ant javatest regrtest" on Windows 7 and on Linux before committing > the 1.6 to 1.7 change, with only the usual failures. (Slightly fewer on > 1.7.) > > Is this just running Jython at the prompt? Say if there's something you'd > like me to try on my platforms. Weird - is it the same if you run "ant clean" first? This problem occurs in the .class files that are generated for each .py file - if they where compiled before with 1.6 you wouldn't see it. If not maybe the JVM on OSX is more sensitive to this. I found the patch from Shashank Bharadwaj - it is here: https://bitbucket.org/shashank/jython-mq/src/tip/fix-asm-via-cfg.patch -- but when I tried to evaluate it back then it had some trouble with doctests that I didn't quite figure out. This may up the priority on getting that patch figured out. -Frank |
From: Indra T. <ind...@gm...> - 2014-03-24 06:16:22
|
On 23 March 2014 04:26, Jeff Allen <ja...@fa...> wrote: > … > > I'm largely content to be guided by others on the project about what's > good enough to release, but Jim's analysis strikes me as optimistic. We > have quite a lot of fails and skips in the regression tests, and sometimes > they represent knotty issues. On the plus side, when we fix a knotty one, > we get rid of several skips at once. This is where my energy goes at the > moment. Good fun if anyone wants to join in. > > Jeff > Speaking of fixing regression tests I have a pull request at https://bitbucket.org/jython/jython/pull-request/22/fixes-for-bz2-module/diffthat fixes all but one of the test_bz2 unittests with that last test requiring an update to commons-compress 1.8 to pull in the fix for https://issues.apache.org/jira/browse/COMPRESS-253. Incidentally fixing up the bz2 module also fixes all bar one of the test_tar unittests. Cheers Indra |
From: Indra T. <ind...@gm...> - 2014-03-29 05:32:02
|
On 24 March 2014 17:16, Indra Talip <ind...@gm...> wrote: > > > On 23 March 2014 04:26, Jeff Allen <ja...@fa...> wrote: > >> … >> >> I'm largely content to be guided by others on the project about what's >> good enough to release, but Jim's analysis strikes me as optimistic. We >> have quite a lot of fails and skips in the regression tests, and sometimes >> they represent knotty issues. On the plus side, when we fix a knotty one, >> we get rid of several skips at once. This is where my energy goes at the >> moment. Good fun if anyone wants to join in. >> >> Jeff >> > > Speaking of fixing regression tests I have a pull request at > https://bitbucket.org/jython/jython/pull-request/22/fixes-for-bz2-module/diffthat fixes all but one of the test_bz2 unittests with that last test > requiring an update to commons-compress 1.8 to pull in the fix for > https://issues.apache.org/jira/browse/COMPRESS-253. Incidentally fixing > up the bz2 module also fixes all bar one of the test_tar unittests. > > Cheers > Indra > I took a look at some of the other failing regression tests and fixed the test_glob tests and have pushed up a pull request to https://bitbucket.org/jython/jython/pull-request/29/fix-regression-tests-for-test_glob/diff Due to the use of java.nio.file.Path it does require that Jython be compiled with Java 7. Cheers Indra -- Indra Talip |
From: Jeff A. <ja...@fa...> - 2014-03-24 19:59:00
|
That would be a welcome change. Last time I looked, test_tarfile was as far as the buildbot could go (on Java 6). All: I guess we're not thinking of this for beta 2 at the moment. Is a review on someone's to do list? Jeff Jeff Allen On 24/03/2014 06:16, Indra Talip wrote: > > > On 23 March 2014 04:26, Jeff Allen <ja...@fa... > <mailto:ja...@fa...>> wrote: > > … > > I'm largely content to be guided by others on the project about > what's good enough to release, but Jim's analysis strikes me as > optimistic. We have quite a lot of fails and skips in the > regression tests, and sometimes they represent knotty issues. On > the plus side, when we fix a knotty one, we get rid of several > skips at once. This is where my energy goes at the moment. Good > fun if anyone wants to join in. > > Jeff > > > Speaking of fixing regression tests I have a pull request at > https://bitbucket.org/jython/jython/pull-request/22/fixes-for-bz2-module/diff > that fixes all but one of the test_bz2 unittests with that last test > requiring an update to commons-compress 1.8 to pull in the fix for > https://issues.apache.org/jira/browse/COMPRESS-253. Incidentally > fixing up the bz2 module also fixes all bar one of the test_tar unittests. > > Cheers > Indra |
From: <fwi...@gm...> - 2014-03-30 17:28:08
|
On Mon, Mar 24, 2014 at 12:58 PM, Jeff Allen <ja...@fa...> wrote: > That would be a welcome change. Last time I looked, test_tarfile was as > far as the buildbot could go (on Java 6). > > All: > > I guess we're not thinking of this for beta 2 at the moment. Is a review > on someone's to do list? > On my medium term list is a review of all of the pull requests, with this one high on the list, but I know I'm not going to get to this for at least a couple of weeks. If anyone wants to have a look before I get to this please do! > > Jeff > > Jeff Allen > > On 24/03/2014 06:16, Indra Talip wrote: > > > > On 23 March 2014 04:26, Jeff Allen <ja...@fa...> wrote: > >> ... >> >> I'm largely content to be guided by others on the project about what's >> good enough to release, but Jim's analysis strikes me as optimistic. We >> have quite a lot of fails and skips in the regression tests, and sometimes >> they represent knotty issues. On the plus side, when we fix a knotty one, >> we get rid of several skips at once. This is where my energy goes at the >> moment. Good fun if anyone wants to join in. >> >> Jeff >> > > Speaking of fixing regression tests I have a pull request at > https://bitbucket.org/jython/jython/pull-request/22/fixes-for-bz2-module/diffthat fixes all but one of the test_bz2 unittests with that last test > requiring an update to commons-compress 1.8 to pull in the fix for > https://issues.apache.org/jira/browse/COMPRESS-253. Incidentally fixing > up the bz2 module also fixes all bar one of the test_tar unittests. > > Cheers > Indra > > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > > |
From: Jeff A. <ja...@fa...> - 2014-03-25 09:20:16
|
On 24/03/2014 21:06, fwi...@gm... wrote: > > On Mon, Mar 24, 2014 at 12:43 PM, Jeff Allen <ja...@fa... > <mailto:ja...@fa...>> wrote: > > That's not a display that means a huge lot to me. jython.java:213 > is a first call to PySystemState.getBaseProperties(), so I guess > the error is while loading PySystemState? > > I ran "ant javatest regrtest" on Windows 7 and on Linux before > committing the 1.6 to 1.7 change, with only the usual failures. > (Slightly fewer on 1.7.) > > Is this just running Jython at the prompt? Say if there's > something you'd like me to try on my platforms. > > > Weird - is it the same if you run "ant clean" first? This problem > occurs in the .class files that are generated for each .py file - if > they where compiled before with 1.6 you wouldn't see it. If not maybe > the JVM on OSX is more sensitive to this. I found the patch from > Shashank Bharadwaj - it is here: > https://bitbucket.org/shashank/jython-mq/src/tip/fix-asm-via-cfg.patch > -- but when I tried to evaluate it back then it had some trouble with > doctests that I didn't quite figure out. This may up the priority on > getting that patch figured out. > > -Frank I've usually run ant clean first, and the notes show I did so in this case (on Windows at least, so probably on Linux too). I've been using the Java 7 compiler since about Christmas, only the setting in build.xml has changed. Lately I've been changing the compiler on my path, therefore the one ant uses, between 6 and 7 as I noticed differences in the failures of float-related tests. I haven't seen what you report. When I'm in Eclipse, it uses a different compiler from the one on my path for Ant, and sometimes I have problems from that, with the exposer, or anonymous classes not found, or when remote debugging. I could try some abusive mixtures, but you seem to have the opposite problem. Jeff Jeff Allen |
From: Jim B. <jb...@zy...> - 2014-04-22 21:19:56
|
The underlying problem is an old version of Jar Jar Links, as reported in http://bugs.jython.org/issue2129 and subsequently fixed. I have upgraded Jar Jar Links from 0.7 to 1.4 and pushed the fix to hg.python.org/jython The reason Jeff didn't see the issue (nor did I) is that we are looking at the regrtest, which uses dist/jython-dev.jar. Frank was instead working against dist/jython.jar, which depends on the Jar Jar Links task to renames classes contained in jars in extlibs to be under org.python in the Java namespace. Once I realized the problem was seen in the difference between running jython-dev.jar and jython.jar (which can be observed with dist/bin/jython --print), the solution was obvious. - Jim On Tue, Mar 25, 2014 at 3:19 AM, Jeff Allen <ja...@fa...> wrote: > On 24/03/2014 21:06, fwi...@gm... wrote: > > > On Mon, Mar 24, 2014 at 12:43 PM, Jeff Allen <ja...@fa...> wrote: > >> That's not a display that means a huge lot to me. jython.java:213 is a >> first call to PySystemState.getBaseProperties(), so I guess the error is >> while loading PySystemState? >> >> I ran "ant javatest regrtest" on Windows 7 and on Linux before committing >> the 1.6 to 1.7 change, with only the usual failures. (Slightly fewer on >> 1.7.) >> >> Is this just running Jython at the prompt? Say if there's something you'd >> like me to try on my platforms. > > > Weird - is it the same if you run "ant clean" first? This problem occurs > in the .class files that are generated for each .py file - if they where > compiled before with 1.6 you wouldn't see it. If not maybe the JVM on OSX > is more sensitive to this. I found the patch from Shashank Bharadwaj - it > is here: > https://bitbucket.org/shashank/jython-mq/src/tip/fix-asm-via-cfg.patch -- > but when I tried to evaluate it back then it had some trouble with doctests > that I didn't quite figure out. This may up the priority on getting that > patch figured out. > > -Frank > > > I've usually run ant clean first, and the notes show I did so in this case > (on Windows at least, so probably on Linux too). I've been using the Java 7 > compiler since about Christmas, only the setting in build.xml has changed. > Lately I've been changing the compiler on my path, therefore the one ant > uses, between 6 and 7 as I noticed differences in the failures of > float-related tests. I haven't seen what you report. > > When I'm in Eclipse, it uses a different compiler from the one on my path > for Ant, and sometimes I have problems from that, with the exposer, or > anonymous classes not found, or when remote debugging. I could try some > abusive mixtures, but you seem to have the opposite problem. > > Jeff > > Jeff Allen > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev > > |
From: Jim B. <jb...@zy...> - 2014-04-22 23:51:26
|
A related point: there are a number of other bugs related to old extlib jars: http://bugs.jython.org/issue2087 - update Guava http://bugs.jython.org/issue2092 - update to JLine2 http://bugs.jython.org/issue2110 - update JNR-Posix There may be others in the bugs db. Once socket-reboot is merged in with beta 3, I'm personally planning to do a comprehensive review of all our extlibs to bring them to their latest version for beta 4. Unless of course we need to do it sooner, as seen in this bug; or someone wants to do it first :). - Jim On Tue, Apr 22, 2014 at 3:19 PM, Jim Baker <jb...@zy...> wrote: > The underlying problem is an old version of Jar Jar Links, as reported in > http://bugs.jython.org/issue2129 and subsequently fixed. I have upgraded > Jar Jar Links from 0.7 to 1.4 and pushed the fix to hg.python.org/jython > > The reason Jeff didn't see the issue (nor did I) is that we are looking at > the regrtest, which uses dist/jython-dev.jar. Frank was instead working > against dist/jython.jar, which depends on the Jar Jar Links task to renames > classes contained in jars in extlibs to be under org.python in the Java > namespace. Once I realized the problem was seen in the difference between > running jython-dev.jar and jython.jar (which can be observed with > dist/bin/jython --print), the solution was obvious. > > - Jim > > > On Tue, Mar 25, 2014 at 3:19 AM, Jeff Allen <ja...@fa...> wrote: > >> On 24/03/2014 21:06, fwi...@gm... wrote: >> >> >> On Mon, Mar 24, 2014 at 12:43 PM, Jeff Allen <ja...@fa...> wrote: >> >>> That's not a display that means a huge lot to me. jython.java:213 is a >>> first call to PySystemState.getBaseProperties(), so I guess the error is >>> while loading PySystemState? >>> >>> I ran "ant javatest regrtest" on Windows 7 and on Linux before >>> committing the 1.6 to 1.7 change, with only the usual failures. (Slightly >>> fewer on 1.7.) >>> >>> Is this just running Jython at the prompt? Say if there's something >>> you'd like me to try on my platforms. >> >> >> Weird - is it the same if you run "ant clean" first? This problem >> occurs in the .class files that are generated for each .py file - if they >> where compiled before with 1.6 you wouldn't see it. If not maybe the JVM on >> OSX is more sensitive to this. I found the patch from Shashank Bharadwaj - >> it is here: >> https://bitbucket.org/shashank/jython-mq/src/tip/fix-asm-via-cfg.patch-- but when I tried to evaluate it back then it had some trouble with >> doctests that I didn't quite figure out. This may up the priority on >> getting that patch figured out. >> >> -Frank >> >> >> I've usually run ant clean first, and the notes show I did so in this >> case (on Windows at least, so probably on Linux too). I've been using the >> Java 7 compiler since about Christmas, only the setting in build.xml has >> changed. Lately I've been changing the compiler on my path, therefore the >> one ant uses, between 6 and 7 as I noticed differences in the failures of >> float-related tests. I haven't seen what you report. >> >> When I'm in Eclipse, it uses a different compiler from the one on my path >> for Ant, and sometimes I have problems from that, with the exposer, or >> anonymous classes not found, or when remote debugging. I could try some >> abusive mixtures, but you seem to have the opposite problem. >> >> Jeff >> >> Jeff Allen >> >> >> >> ------------------------------------------------------------------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and their >> applications. Written by three acclaimed leaders in the field, >> this first edition is now available. Download your free book today! >> http://p.sf.net/sfu/13534_NeoTech >> _______________________________________________ >> Jython-dev mailing list >> Jyt...@li... >> https://lists.sourceforge.net/lists/listinfo/jython-dev >> >> > |
From: Jeff A. <ja...@fa...> - 2014-04-23 21:51:58
|
Well done. I'd forgotten the jarjar thing was going on. I would add the old ANTLR jars to that list for consideration. (We can't still need 2.7.7, surely?) However, port to the latest is easy to say (http://bugs.jython.org/issue1903). Jeff Allen On 23/04/2014 00:50, Jim Baker wrote: > A related point: there are a number of other bugs related to old > extlib jars: > > http://bugs.jython.org/issue2087 - update Guava > http://bugs.jython.org/issue2092 - update to JLine2 > http://bugs.jython.org/issue2110 - update JNR-Posix > > There may be others in the bugs db. Once socket-reboot is merged in > with beta 3, I'm personally planning to do a comprehensive review of > all our extlibs to bring them to their latest version for beta 4. > Unless of course we need to do it sooner, as seen in this bug; or > someone wants to do it first :). > > - Jim > > On Tue, Apr 22, 2014 at 3:19 PM, Jim Baker <jb...@zy... > <mailto:jb...@zy...>> wrote: > > The underlying problem is an old version of Jar Jar Links, as > reported in http://bugs.jython.org/issue2129 and subsequently > fixed. I have upgraded Jar Jar Links from 0.7 to 1.4 and pushed > the fix to hg.python.org/jython <http://hg.python.org/jython> > > The reason Jeff didn't see the issue (nor did I) is that we are > looking at the regrtest, which uses dist/jython-dev.jar. Frank was > instead working against dist/jython.jar, which depends on the Jar > Jar Links task to renames classes contained in jars in extlibs to > be under org.python in the Java namespace. Once I realized the > problem was seen in the difference between running jython-dev.jar > and jython.jar (which can be observed with dist/bin/jython > --print), the solution was obvious. > > - Jim > > > On Tue, Mar 25, 2014 at 3:19 AM, Jeff Allen <ja...@fa... > <mailto:ja...@fa...>> wrote: > > On 24/03/2014 21:06, fwi...@gm... > <mailto:fwi...@gm...> wrote: >> >> On Mon, Mar 24, 2014 at 12:43 PM, Jeff Allen >> <ja...@fa... <mailto:ja...@fa...>> wrote: >> >> That's not a display that means a huge lot to me. >> jython.java:213 is a first call to >> PySystemState.getBaseProperties(), so I guess the error >> is while loading PySystemState? >> >> I ran "ant javatest regrtest" on Windows 7 and on Linux >> before committing the 1.6 to 1.7 change, with only the >> usual failures. (Slightly fewer on 1.7.) >> >> Is this just running Jython at the prompt? Say if there's >> something you'd like me to try on my platforms. >> >> >> Weird - is it the same if you run "ant clean" first? This >> problem occurs in the .class files that are generated for >> each .py file - if they where compiled before with 1.6 you >> wouldn't see it. If not maybe the JVM on OSX is more >> sensitive to this. I found the patch from Shashank Bharadwaj >> - it is here: >> https://bitbucket.org/shashank/jython-mq/src/tip/fix-asm-via-cfg.patch >> -- but when I tried to evaluate it back then it had some >> trouble with doctests that I didn't quite figure out. This >> may up the priority on getting that patch figured out. >> >> -Frank > > I've usually run ant clean first, and the notes show I did so > in this case (on Windows at least, so probably on Linux too). > I've been using the Java 7 compiler since about Christmas, > only the setting in build.xml has changed. Lately I've been > changing the compiler on my path, therefore the one ant uses, > between 6 and 7 as I noticed differences in the failures of > float-related tests. I haven't seen what you report. > > When I'm in Eclipse, it uses a different compiler from the one > on my path for Ant, and sometimes I have problems from that, > with the exposer, or anonymous classes not found, or when > remote debugging. I could try some abusive mixtures, but you > seem to have the opposite problem. > > Jeff > > Jeff Allen > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph > databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book > today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > <mailto:Jyt...@li...> > https://lists.sourceforge.net/lists/listinfo/jython-dev > > > |