Re: [VOTE]: Release Proton 0.9.1-rc1 as 0.9.1
On 29 April 2015 at 20:34, Rafael Schloming r...@alum.mit.edu wrote: Hi Everyone, I've put out an RC for 0.9.1 in the usual places. Source artifacts are here: https://people.apache.org/~rhs/qpid-proton-0.9.1-rc1/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-1033 Please check them out and register your vote: [ ]: Yes, release Proton 0.9.1-rc1 as 0.9.1 [ ]: No, ... --Rafael [ +1 ]: Yes, release Proton 0.9.1-rc1 as 0.9.1 I kicked the tyres by doing the following: - Ran the cmake build with the tests. - Ran the Maven build with the tests. - Verified the sigs+checksums. - Checked the LICENCE+NOTICE looked ok. - Used the staging repo to run the Qpid JMS master build+tests. - Used the staging repo to run the ActiveMQ master build and AMQP module tests. - Verified that a reproducer which identified some of the issues fixed in the release now runs ok. I noticed while running the cmake build that PN_VERSION got logged as being set to 0.9, which made the cmake-built jar get a name with 0.9, and from chatting to Rafi probably also means the versions available within the C/Python code dont have access to the point release number. We both think this is ok for now, but something we possibly want to fix on master for future, for which I have raised PROTON-874. Robbie P.S, anyone wanting to test things out using the staged maven artifacts can add this to your pom: repositories repository idstaging/id urlhttps://repository.apache.org/content/repositories/orgapacheqpid-1033/url /repository /repositories
[jira] [Created] (PROTON-874) PN_VERSION only supports major and minor versions
Robbie Gemmell created PROTON-874: - Summary: PN_VERSION only supports major and minor versions Key: PROTON-874 URL: https://issues.apache.org/jira/browse/PROTON-874 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Robbie Gemmell Priority: Minor The cmake build reads in PN_VERSION from the version file, but it only supports major and minor versions. It seems to be used in the file name for the cmake-built jar, and within code to make the version available to C/Python code. This should be updated to support micro/patch version info. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Python 3 port is 'done'
On Thu, Apr 30, 2015 at 8:35 AM, Ken Giusti kgiu...@redhat.com wrote: - Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Wednesday, April 29, 2015 4:24:09 PM Subject: Re: Python 3 port is 'done' What happens when I run make test and I have both python2 and python3 installed on my system? Do the tests run once under each version or does one of the versions 'win'? At this point it only runs on the 'default' version - whatever /usr/bin/python resolves to. I like the idea of having it run on all installed python versions, but I haven't explored how to do that yet. I've been using virtualenv [1] to switch between the two versions of python I have installed on my development station. Tox [2] is probably the best approach to enable testing against multiple python environments. I'll look into tox a bit and see what I can come up with. My system comes with both python and python3 on my path. Just running python3 manually on proton/tests/proton-test will run it with the python3 interpreter. I don't know how standard this setup is (I'm running stock fedora 20), but it would be pretty easy to do a check in cmake and run the tests using python3 if present. I'm also a fan of running both python versions if present, but I also don't want to double the time it takes to run through the tests. Given that we are mostly looking for syntactic incompatibilities in the wrapper code here, I wonder if it would be sufficient to run a subset of the tests that is likely to give us good coverage on the wrapper code but doesn't bother trying to exercise all the C code twice. Obviously if this proves insufficient we could expand the subset. --Rafael
Re: Python 3 port is 'done'
- Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Thursday, April 30, 2015 9:00:14 AM Subject: Re: Python 3 port is 'done' On Thu, Apr 30, 2015 at 8:35 AM, Ken Giusti kgiu...@redhat.com wrote: - Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Wednesday, April 29, 2015 4:24:09 PM Subject: Re: Python 3 port is 'done' What happens when I run make test and I have both python2 and python3 installed on my system? Do the tests run once under each version or does one of the versions 'win'? At this point it only runs on the 'default' version - whatever /usr/bin/python resolves to. I like the idea of having it run on all installed python versions, but I haven't explored how to do that yet. I've been using virtualenv [1] to switch between the two versions of python I have installed on my development station. Tox [2] is probably the best approach to enable testing against multiple python environments. I'll look into tox a bit and see what I can come up with. My system comes with both python and python3 on my path. Just running python3 manually on proton/tests/proton-test will run it with the python3 interpreter. I don't know how standard this setup is (I'm running stock fedora 20), but it would be pretty easy to do a check in cmake and run the tests using python3 if present. I'm also a fan of running both python versions if present, but I also don't want to double the time it takes to run through the tests. Given that we are mostly looking for syntactic incompatibilities in the wrapper code here, I wonder if it would be sufficient to run a subset of the tests that is likely to give us good coverage on the wrapper code but doesn't bother trying to exercise all the C code twice. Obviously if this proves insufficient we could expand the subset. Oh yeah - totally agreed. Just some smaller subset of python-test would make me happy. I found most problems were covered by the engine, codec, transport test modules btw. If that's all we need, then simply running python3 directly on the unit tests makes the most sense. --Rafael -- -K
beware stale snapshots
The versions of the Proton pom files were changed on master yesterday to 0.10-SNAPSHOT (i.e next-release-SNAPSHOT), from their previous constant use of 1.0-SNAPSHOT regardless of the next release version. As a result of this the nightly snapshot job is now publishing with the new version, which means there are currently stale artifiacts in the snapshot repo with the previous version. If you want current snapshots you need to update your dependencies accordingly. I decided to raise a JIRA to request INFRA nuke the stale artifacts. In doing so I went through all the published org.apache.qpid.* artifacts and found a significant number of stale versions or artifact names from the past, so I have asked for all of those to be removed as well: https://issues.apache.org/jira/browse/INFRA-9561 Given the extent of the mess we have made, its possible the best way forward could be for infra to simply delete everything and then we republish current snapshots. That would create a small window where no snapshot is available when requested, so I'll send an update if that is how things proceed. Robbie
Re: Python 3 port is 'done'
- Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Wednesday, April 29, 2015 4:24:09 PM Subject: Re: Python 3 port is 'done' What happens when I run make test and I have both python2 and python3 installed on my system? Do the tests run once under each version or does one of the versions 'win'? At this point it only runs on the 'default' version - whatever /usr/bin/python resolves to. I like the idea of having it run on all installed python versions, but I haven't explored how to do that yet. I've been using virtualenv [1] to switch between the two versions of python I have installed on my development station. Tox [2] is probably the best approach to enable testing against multiple python environments. I'll look into tox a bit and see what I can come up with. -K [1] http://docs.python-guide.org/en/latest/dev/virtualenvs/ [2] https://tox.readthedocs.org/en/latest/ --Rafael On Wed, Apr 29, 2015 at 4:05 PM, Ken Giusti kgiu...@redhat.com wrote: Well, done enough to consider merging to master. While the patch is quite large, most of the changes are simple syntax changes to avoid non-python3 compliant syntax. The code is available on the kgiusti-python3 branch at the Apache repo. https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=shortlog;h=refs/heads/kgiusti-python3 I've also made a patch that can be viewed up on reviewboard: https://reviews.apache.org/r/33691/ I've verified that the unit tests and python examples run under python2.6, 2.7, and python3.3. I'd appreciate if folks would take this patch for a spin and report back their experience. Known Issues: These changes will be incompatible with earlier versions of the python 2.x series. I know for a fact that python versions = 2.4 won't even parse this patch, and I suspect getting such older versions of python to work would require lots of effort. I'm a little unsure of how well python 2.5 will be supported - I have yet to test that far back. I also didn't test anything earlier than 3.3 in the python3.x stream. -- -K -- -K
[jira] [Resolved] (PROTON-874) PN_VERSION only supports major and minor versions
[ https://issues.apache.org/jira/browse/PROTON-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-874. Resolution: Fixed Fix Version/s: 0.10 PN_VERSION only supports major and minor versions - Key: PROTON-874 URL: https://issues.apache.org/jira/browse/PROTON-874 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9.1 Reporter: Robbie Gemmell Assignee: Rafael H. Schloming Priority: Minor Fix For: 0.10 The cmake build reads in PN_VERSION from the version file, but it only supports major and minor versions. It seems to be used in the file name for the cmake-built jar, and within code to make the version available to C/Python code. This should be updated to support micro/patch version info. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Python 3 port is 'done'
- Original Message - From: Ken Giusti kgiu...@redhat.com To: proton@qpid.apache.org Cc: us...@qpid.apache.org Sent: Thursday, April 30, 2015 9:18:26 AM Subject: Re: Python 3 port is 'done' - Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Thursday, April 30, 2015 9:00:14 AM Subject: Re: Python 3 port is 'done' On Thu, Apr 30, 2015 at 8:35 AM, Ken Giusti kgiu...@redhat.com wrote: - Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Wednesday, April 29, 2015 4:24:09 PM Subject: Re: Python 3 port is 'done' What happens when I run make test and I have both python2 and python3 installed on my system? Do the tests run once under each version or does one of the versions 'win'? At this point it only runs on the 'default' version - whatever /usr/bin/python resolves to. I like the idea of having it run on all installed python versions, but I haven't explored how to do that yet. I've been using virtualenv [1] to switch between the two versions of python I have installed on my development station. Tox [2] is probably the best approach to enable testing against multiple python environments. I'll look into tox a bit and see what I can come up with. My system comes with both python and python3 on my path. Just running python3 manually on proton/tests/proton-test will run it with the python3 interpreter. I don't know how standard this setup is (I'm running stock fedora 20), but it would be pretty easy to do a check in cmake and run the tests using python3 if present. I'm also a fan of running both python versions if present, but I also don't want to double the time it takes to run through the tests. Given that we are mostly looking for syntactic incompatibilities in the wrapper code here, I wonder if it would be sufficient to run a subset of the tests that is likely to give us good coverage on the wrapper code but doesn't bother trying to exercise all the C code twice. Obviously if this proves insufficient we could expand the subset. Oh yeah - totally agreed. Just some smaller subset of python-test would make me happy. I found most problems were covered by the engine, codec, transport test modules btw. If that's all we need, then simply running python3 directly on the unit tests makes the most sense. Ah, turns out the 'hard problem' is not running the tests, but building both py2 and py3 binaries from the c-wrapper. Totally different include and link libraries and different install paths. Cmake doesn't appear to directly support this - it only resolves to one instance of python, though that instance can be configured. But nowhere does it provide a list of available pythons - we'd have to script that ourselves. Once we have that list, we should use the setup.py script to build/install the language specific module. setup.py already handles swig, so simply invoking setup.py for each available python interpreter would do all the heavy lifting. thoughts? --Rafael -- -K -- -K
[jira] [Commented] (PROTON-865) C++ reactor client binding
[ https://issues.apache.org/jira/browse/PROTON-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521993#comment-14521993 ] ASF subversion and git services commented on PROTON-865: Commit 177def1345733d8dcfbc2498b9b154712f7b85b6 in qpid-proton's branch refs/heads/cjansen-cpp-client from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=177def1 ] PROTON-865: new cjansen-cpp-client branch for fledgling C++ client code using the event reactor C++ reactor client binding -- Key: PROTON-865 URL: https://issues.apache.org/jira/browse/PROTON-865 Project: Qpid Proton Issue Type: New Feature Environment: C++ Reporter: Cliff Jansen Assignee: Cliff Jansen This JIRA tracks initial work on a C++ binding to the Proton reactor event based model with an eye to providing an API very similar to the python client. As stated on the Proton list, the broad goals are: to make it easy to write simple programs natural to build out more complicated ones very similar API to the Python client lean and performant The initial introduction with accompanying HelloWorld can be found at https://github.com/apache/qpid-proton/pull/18 Ongoing work is proceeding in my github account in branch cpp-work https://github.com/cliffjansen/qpid-proton/tree/cpp-work commit 1453f57ca3f446450ef654505548f1947cb7a0f1 adds listener support, exceptions and a logging interface. The initial implementation will provide no thread safety guarantees, but the bone structure should allow that to be added later with no API change. I still hold out hope of eventually allowing multiple threads processing separate connections concurrently. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-727) Add a NULL-pointer checks to malloc() and realloc() calls
[
https://issues.apache.org/jira/browse/PROTON-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521813#comment-14521813
]
ASF GitHub Bot commented on PROTON-727:
---
GitHub user dcristoloveanu opened a pull request:
https://github.com/apache/qpid-proton/pull/27
Add some NULL checks and fix some realloc leaks
Along the lines of PROTON-727, added NULL checks for some malloc/realloc
calls that were either ignoring the result or leaking in the case of realloc.
Thanks,
/Dan
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/dcristoloveanu/qpid-proton FixCodeAnalysis
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-proton/pull/27.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #27
commit c31b068656579b3b6e47a44bd97b40001f2a66ca
Author: dcristoloveanu dcri...@microsoft.com
Date: 2015-04-30T00:15:51Z
Add some NULL checks and fix some realloc leaks
Add a NULL-pointer checks to malloc() and realloc() calls
-
Key: PROTON-727
URL: https://issues.apache.org/jira/browse/PROTON-727
Project: Qpid Proton
Issue Type: Wish
Components: proton-c
Affects Versions: 0.8
Reporter: German Shepherd (PrE)
Priority: Minor
As we are running the ProtonC project on memory constrained systems, it is
possible for malloc() or realloc() to return a NULL, when there is no more
free heap to allocate the memory from.
Obviously, we might have a specific optimizations in the ProtonC code, which
deeply minimize the amount of a total heap required, but this is not what
this ticket is referring to.
In any case where there is no more free heap, or in a case where there is any
other issue with the allocators, the memory allocation functions return NULL.
The ProtonC code at this state, does not check for such a situation, and it
always expects the malloc() and realloc() to work and to return a valid
pointer.
I would like the developers to add a specific test to each place, where
memory allocation takes place, and to act upon an error properly (ideally -
with a graceful closure of the connection to broker, if possible).
Also, a proper signalization path to the user's application (which runs the
ProtonC client) would be a great addition.
If nothing fancy is planned, I would, at least, ask for adding the simple {{
if (x == NULL) { do something }; }} tests to each every place where memory
allocation is handled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] qpid-proton pull request: Add some NULL checks and fix some reallo...
GitHub user dcristoloveanu opened a pull request: https://github.com/apache/qpid-proton/pull/27 Add some NULL checks and fix some realloc leaks Along the lines of PROTON-727, added NULL checks for some malloc/realloc calls that were either ignoring the result or leaking in the case of realloc. Thanks, /Dan You can merge this pull request into a Git repository by running: $ git pull https://github.com/dcristoloveanu/qpid-proton FixCodeAnalysis Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/27.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #27 commit c31b068656579b3b6e47a44bd97b40001f2a66ca Author: dcristoloveanu dcri...@microsoft.com Date: 2015-04-30T00:15:51Z Add some NULL checks and fix some realloc leaks --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Question about pn_reactor and threads.
Can the proton reactor be used to deliver work from multiple connections to a thread pool, where work from a given connection is only handled by one thread at a time (so access to each pn_transport and it's stuff is serialized)? That is a pretty standard model for servers. It doesn't look to me like this is the case but I may be missing something. If it is the case, what's the pattern for doing it? Cheers, Alan.
Re: Question about pn_reactor and threads.
Hi Alan, I've been playing with the reactor a bit, and one of my early thoughts was: how do you scale this thing across multiple cores? The architecture I've worked with before uses (approximately) one selector + thread pair per core and balances connections across the selectors. Anything non-blocking is done on the selector/thread pair (to avoid context switches and maintain a small working set for each thread). Anything with the potential to block gets dispatched into a thread pool. I /think/ the way you would use the reactor for this kind of architecture is to have one reactor + thread pair per core. That said, I've not tested this hypothesis. If the architecture that you're thinking of always dispatches ready file descriptors into a pool of threads - then I'm _not_ sure that this is something that the reactor (as it currently stands) can easily be slotted into. Regards - Adrian -Alan Conway acon...@redhat.com wrote: - To: proton@qpid.apache.org From: Alan Conway acon...@redhat.com Date: 04/30/2015 07:47PM Subject: Question about pn_reactor and threads. Can the proton reactor be used to deliver work from multiple connections to a thread pool, where work from a given connection is only handled by one thread at a time (so access to each pn_transport and it's stuff is serialized)? That is a pretty standard model for servers. It doesn't look to me like this is the case but I may be missing something. If it is the case, what's the pattern for doing it? Cheers, Alan. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
0.10 release time frame?
I'm interested in knowing the timelines the community has in mind for the 0.10 release. A tentative date for alpha and beta cycles would be helpful in planning the work tasks and vacation time. Regards, Rajith
Re: Python 3 port is 'done'
Failures on Windows (beyond the four SASL failures in PROTON-875) running Python 2.6.1 37 MessengerTests tests (all that aren't skipped) fail with Unexpected input while waiting for receiver to initialize: READY - Original Message - From: Ken Giusti kgiu...@redhat.com To: proton@qpid.apache.org, us...@qpid.apache.org Sent: Wednesday, April 29, 2015 4:05:32 PM Subject: Python 3 port is 'done' Well, done enough to consider merging to master. While the patch is quite large, most of the changes are simple syntax changes to avoid non-python3 compliant syntax. The code is available on the kgiusti-python3 branch at the Apache repo. https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=shortlog;h=refs/heads/kgiusti-python3 I've also made a patch that can be viewed up on reviewboard: https://reviews.apache.org/r/33691/ I've verified that the unit tests and python examples run under python2.6, 2.7, and python3.3. I'd appreciate if folks would take this patch for a spin and report back their experience. Known Issues: These changes will be incompatible with earlier versions of the python 2.x series. I know for a fact that python versions = 2.4 won't even parse this patch, and I suspect getting such older versions of python to work would require lots of effort. I'm a little unsure of how well python 2.5 will be supported - I have yet to test that far back. I also didn't test anything earlier than 3.3 in the python3.x stream. -- -K - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Question about pn_reactor and threads.
What sort of work/connections are you talking about here? Are you talking about processing AMQP messages in a thread pool or are you talking about writing some sort of multithreaded I/O handler? --Rafael On Thu, Apr 30, 2015 at 2:47 PM, Alan Conway acon...@redhat.com wrote: Can the proton reactor be used to deliver work from multiple connections to a thread pool, where work from a given connection is only handled by one thread at a time (so access to each pn_transport and it's stuff is serialized)? That is a pretty standard model for servers. It doesn't look to me like this is the case but I may be missing something. If it is the case, what's the pattern for doing it? Cheers, Alan.
Re: 0.10 release time frame?
I'd like to see one fairly soon. I'm currently working through a few sasl-related interop issues between proton-c and proton-j, but once that is done and gordon's map fix lands, I think we would be in decent shape to put out a 0.10 in short order. --Rafael On Thu, Apr 30, 2015 at 3:06 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: I'm interested in knowing the timelines the community has in mind for the 0.10 release. A tentative date for alpha and beta cycles would be helpful in planning the work tasks and vacation time. Regards, Rajith
Re: [VOTE]: Release Proton 0.9.1-rc1 as 0.9.1
On 04/29/2015 03:34 PM, Rafael Schloming wrote: Hi Everyone, I've put out an RC for 0.9.1 in the usual places. Source artifacts are here: https://people.apache.org/~rhs/qpid-proton-0.9.1-rc1/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-1033 Please check them out and register your vote: [ ]: Yes, release Proton 0.9.1-rc1 as 0.9.1 [ ]: No, ... --Rafael +1 * Built and ran tests from the source bundle * Tested ActiveMQ using the staging artifacts -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com twitter: @tabish121 blog: http://timbish.blogspot.com/
Re: Python 3 port is 'done'
On 29 April 2015 at 21:05, Ken Giusti kgiu...@redhat.com wrote: Well, done enough to consider merging to master. While the patch is quite large, most of the changes are simple syntax changes to avoid non-python3 compliant syntax. The code is available on the kgiusti-python3 branch at the Apache repo. https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=shortlog;h=refs/heads/kgiusti-python3 I've also made a patch that can be viewed up on reviewboard: https://reviews.apache.org/r/33691/ I've verified that the unit tests and python examples run under python2.6, 2.7, and python3.3. I'd appreciate if folks would take this patch for a spin and report back their experience. Known Issues: These changes will be incompatible with earlier versions of the python 2.x series. I know for a fact that python versions = 2.4 won't even parse this patch, and I suspect getting such older versions of python to work would require lots of effort. I'm a little unsure of how well python 2.5 will be supported - I have yet to test that far back. I also didn't test anything earlier than 3.3 in the python3.x stream. -- -K I gave thigns a kick with Python 2.7, and Jython 2.5.3 without issue. I also tried the maven build with Jython 2.7 RC3 (there was a new one) and things exploded similarly to the way they did before. Robbie
[jira] [Created] (PROTON-875) Proton-C SASL changes break windows self tests
Chuck Rolke created PROTON-875:
--
Summary: Proton-C SASL changes break windows self tests
Key: PROTON-875
URL: https://issues.apache.org/jira/browse/PROTON-875
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.9
Environment: Windows Server Datacenter SP2, 32-bit
swigwin-2.0.10
Python26
Reporter: Chuck Rolke
After commits 4a09c6, 7cf0aba, and b3bf328 from PROTON-334, self tests started
to fail.
{noformat}
1: proton_tests.sasl.SaslTest.testPipelined2 ...
fail
1: Error during test: Traceback (most recent call last):
1: File
C:/Jenkins/workspace/rh_qpid_proton-trunk/rh-qpid-proton/tests/python/proton-test,
line 355, in run
1: phase()
1: File
C:\Jenkins\workspace\rh_qpid_proton-trunk\rh-qpid-proton\tests\python\proton_tests\sasl.py,
line 161, in testPipelined2
1: assert len(out1) 0
1: AssertionError
1: proton_tests.sasl.SaslTest.testPipelinedClient ..
fail
1: Error during test: Traceback (most recent call last):
1: File
C:/Jenkins/workspace/rh_qpid_proton-trunk/rh-qpid-proton/tests/python/proton-test,
line 355, in run
1: phase()
1: File
C:\Jenkins\workspace\rh_qpid_proton-trunk\rh-qpid-proton\tests\python\proton_tests\sasl.py,
line 68, in testPipelinedClient
1: assert self.s1.outcome == SASL.OK
1: AssertionError
1: proton_tests.sasl.SaslTest.testPipelinedClientFail ..
fail
1: Error during test: Traceback (most recent call last):
1: File
C:/Jenkins/workspace/rh_qpid_proton-trunk/rh-qpid-proton/tests/python/proton-test,
line 355, in run
1: phase()
1: File
C:\Jenkins\workspace\rh_qpid_proton-trunk\rh-qpid-proton\tests\python\proton_tests\sasl.py,
line 95, in testPipelinedClientFail
1: assert self.s1.outcome == SASL.AUTH
1: AssertionError
1: proton_tests.sasl.SaslTest.testSaslAndAmqpInSingleChunk .
fail
1: Error during test: Traceback (most recent call last):
1: File
C:/Jenkins/workspace/rh_qpid_proton-trunk/rh-qpid-proton/tests/python/proton-test,
line 355, in run
1: phase()
1: File
C:\Jenkins\workspace\rh_qpid_proton-trunk\rh-qpid-proton\tests\python\proton_tests\sasl.py,
line 140, in testSaslAndAmqpInSingleChunk
1: assert self.s2.outcome == SASL.OK
1: AssertionError
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Python 3 port is 'done'
On 30 April 2015 at 15:56, Ken Giusti kgiu...@redhat.com wrote: - Original Message - From: Robbie Gemmell robbie.gemm...@gmail.com To: proton@qpid.apache.org Cc: us...@qpid.apache.org Sent: Thursday, April 30, 2015 10:20:07 AM Subject: Re: Python 3 port is 'done' On 29 April 2015 at 21:05, Ken Giusti kgiu...@redhat.com wrote: Well, done enough to consider merging to master. While the patch is quite large, most of the changes are simple syntax changes to avoid non-python3 compliant syntax. The code is available on the kgiusti-python3 branch at the Apache repo. https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=shortlog;h=refs/heads/kgiusti-python3 I've also made a patch that can be viewed up on reviewboard: https://reviews.apache.org/r/33691/ I've verified that the unit tests and python examples run under python2.6, 2.7, and python3.3. I'd appreciate if folks would take this patch for a spin and report back their experience. Known Issues: These changes will be incompatible with earlier versions of the python 2.x series. I know for a fact that python versions = 2.4 won't even parse this patch, and I suspect getting such older versions of python to work would require lots of effort. I'm a little unsure of how well python 2.5 will be supported - I have yet to test that far back. I also didn't test anything earlier than 3.3 in the python3.x stream. -- -K I gave thigns a kick with Python 2.7, and Jython 2.5.3 without issue. I also tried the maven build with Jython 2.7 RC3 (there was a new one) and things exploded similarly to the way they did before. Thanks Robbie. What kind of issues does Jython 2.7 complain about? I'll have to install that RC at some point... :( -K Lots of the tests fail due to error, most if not all of which seem to be TypeError: Type not compatible with array. As I say though, this isnt to do with your changes since it did that last time I tried too :) If you want to try it, below is change needed. Probably worth making sure you clean out the old .pyc files left by previous test runs (I use git-clean to nuke things back to fresh state). diff --git tests/pom.xml tests/pom.xml index 8367eca..7dcee1e 100644 --- tests/pom.xml +++ tests/pom.xml @@ -93,7 +93,7 @@ directory lt;basedirgt;/build/proton-c./description dependency groupIdorg.python/groupId artifactIdjython-standalone/artifactId -version2.5.3/version +version2.7-rc3/version scopetest/scope /dependency /dependencies
Re: Python 3 port is 'done'
- Original Message - From: Robbie Gemmell robbie.gemm...@gmail.com To: proton@qpid.apache.org Cc: us...@qpid.apache.org Sent: Thursday, April 30, 2015 10:20:07 AM Subject: Re: Python 3 port is 'done' On 29 April 2015 at 21:05, Ken Giusti kgiu...@redhat.com wrote: Well, done enough to consider merging to master. While the patch is quite large, most of the changes are simple syntax changes to avoid non-python3 compliant syntax. The code is available on the kgiusti-python3 branch at the Apache repo. https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=shortlog;h=refs/heads/kgiusti-python3 I've also made a patch that can be viewed up on reviewboard: https://reviews.apache.org/r/33691/ I've verified that the unit tests and python examples run under python2.6, 2.7, and python3.3. I'd appreciate if folks would take this patch for a spin and report back their experience. Known Issues: These changes will be incompatible with earlier versions of the python 2.x series. I know for a fact that python versions = 2.4 won't even parse this patch, and I suspect getting such older versions of python to work would require lots of effort. I'm a little unsure of how well python 2.5 will be supported - I have yet to test that far back. I also didn't test anything earlier than 3.3 in the python3.x stream. -- -K I gave thigns a kick with Python 2.7, and Jython 2.5.3 without issue. I also tried the maven build with Jython 2.7 RC3 (there was a new one) and things exploded similarly to the way they did before. Thanks Robbie. What kind of issues does Jython 2.7 complain about? I'll have to install that RC at some point... :( Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org -- -K
