Re: candidate commits for 0.9.1
On Wed, Apr 29, 2015 at 6:16 AM, Dominic Evans dominic.ev...@uk.ibm.com wrote: -Robbie Gemmell robbie.gemm...@gmail.com wrote: - There were some changes on master and the branch yesterday, so I have updated the commit lists again. The current categorised list of commits is now at: http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass3-c ategorised.txt As before, only the commits at the very bottom have been picked from master to the 0.9.x branch. All the previous commits mentioned in the file have not. If you want anything else included you need to say so, or do so. We are essentially waiting for PROTON-858 at this point, which there still seems to be a lot of discussion going on about. If we cant land it quickly with confidence I'd like to suggest possibly deferring it, as we can always do more releases. Thanks Robbie. Ongoing, is the plan that we should continue to backport cherry-picked bugfix commits from master and keep the 0.9.x series going for possible future point releases? I think the SASL stuff should stabilize soon, and as that is the major delta, we could simply do a 0.10 when that happens. --Rafael
Re: candidate commits for 0.9.1
-Robbie Gemmell robbie.gemm...@gmail.com wrote: - There were some changes on master and the branch yesterday, so I have updated the commit lists again. The current categorised list of commits is now at: http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass3-c ategorised.txt As before, only the commits at the very bottom have been picked from master to the 0.9.x branch. All the previous commits mentioned in the file have not. If you want anything else included you need to say so, or do so. We are essentially waiting for PROTON-858 at this point, which there still seems to be a lot of discussion going on about. If we cant land it quickly with confidence I'd like to suggest possibly deferring it, as we can always do more releases. Thanks Robbie. Ongoing, is the plan that we should continue to backport cherry-picked bugfix commits from master and keep the 0.9.x series going for possible future point releases? -- 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
Re: candidate commits for 0.9.1
There were some changes on master and the branch yesterday, so I have updated the commit lists again. The current categorised list of commits is now at: http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass3-categorised.txt As before, only the commits at the very bottom have been picked from master to the 0.9.x branch. All the previous commits mentioned in the file have not. If you want anything else included you need to say so, or do so. We are essentially waiting for PROTON-858 at this point, which there still seems to be a lot of discussion going on about. If we cant land it quickly with confidence I'd like to suggest possibly deferring it, as we can always do more releases. Robbie On 27 April 2015 at 16:43, Robbie Gemmell robbie.gemm...@gmail.com wrote: Ok I have now cherry picked the commits mentioned earlier by Gordon, Rafael, and Dominic. The current categorised list of commits is now at: http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass2-categorised.txt The bare git cherry -v 0.9.x master output is at: http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass2.txt Robbie On 27 April 2015 at 12:46, Robbie Gemmell robbie.gemm...@gmail.com wrote: I have gone through the git cherry output and categorised the remaining commits from master that dont have a direct equivalent on the 0.9.x branch, splitting according to what they update i.e. mainly by language. I listed some as excluded based on what they are for, e.g the 0.10 sasl work, and any Go-only changes (because the Go bits were not in 0.9). http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1-categorised.txt I'd like to get the 0.9.1 release out this week, which would mean starting a vote tomorrow, so if you want specific commits included then please shout now. Robbie On 25 April 2015 at 21:10, Robbie Gemmell robbie.gemm...@gmail.com wrote: New 0.9.x branch created, against the actual 0.9 tag this time. I have updated the JIRAs for the all the commits included so far to add the 0.9.1 fix version. If you want any commits included, either git cherry-pick -x them to the branch yourself or reply with the SHAs. Output of git cherry -v 0.9.x master after the first pass including commits for proton-j and 1 for proton-c: http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1.txt Robbie snipped
Re: candidate commits for 0.9.1
On 29 April 2015 at 17:38, Gordon Sim g...@redhat.com wrote: On 04/27/2015 01:45 PM, Gordon Sim wrote: On 04/27/2015 01:14 PM, Rafael Schloming wrote: I also added PROTON-858 as a release blocker. I've been trying to get a fix proposal together for that. I'll post it for review as soon as I'm reasonably confident, still seeing some issues at present (not 100% sure they are related, but am assuming so). Just to update the status here. Although I have positive reviews for the simple patch, I have encountered some issues even with that during stress testing. I can't say for sure whether these are caused by my change as the test showing them up doesn't run long enough without the change. However until I know for sure I am not keen to commit it. If this is holding up things for the proton-j side, which after all is what motivated the release in the first place, I would suggest we continue without the fix for PROTON-858. I think that might be a good idea, certainly I wont argue against it. If we arent confident in the fix, we might end up needing a respin that could push things out further. At the end of the day, we can easily do a 0.9.2 when we think it is ready. Its possibly also worth saying that even if we didnt do that, its likely less of an issue for folks using proton-c to just patch the source they build from, whereas many using proton-j will be doing so via binaries at maven central and so need us to push a release out to get the changes. Robbie
[jira] [Commented] (PROTON-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14519710#comment-14519710 ] ASF subversion and git services commented on PROTON-490: Commit 9e7f16ccb5b2240c218af5ace2c4a61f07af1b9c in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9e7f16c ] PROTON-490: fix examples, reactor [proton-c] Python binding fails to link with Python 3 libraries --- Key: PROTON-490 URL: https://issues.apache.org/jira/browse/PROTON-490 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Attachments: 47_proton-490_fix_cproton.i.patch, 47_proton-490_fix_import_statements_mllib_init.patch, 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, 47_proton-490_fix_mllib_transforms.py.patch, 47_proton-490_fix_print_encodings.h.py.patch, 47_proton-490_fix_print_protocol.h.py.patch, 47_proton-490_fix_proton_init.patch Attempting to link the Swig generated python bindings against the Python 3 development libraries produces unresolved symbol errors: CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes_dup': pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_message_get_user_id': pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_decimal128': pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_uuid': pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): more undefined references to `PyString_FromStringAndSize' follow collect2: error: ld returned 1 exit status This is due to a name change in the Python 3 API: http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize http://docs.python.org/2/howto/cporting.html#conditional-compilation The wrapper C code in proton-c/bindings/python/python.i needs to be updated to support the Python 3 API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14519709#comment-14519709 ] ASF subversion and git services commented on PROTON-490: Commit 646ee41cbb1071b60394fd85ec44bc515a19605a in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=646ee41 ] PROTON-490: remove dependency on six, provide simple abstractions for language differences [proton-c] Python binding fails to link with Python 3 libraries --- Key: PROTON-490 URL: https://issues.apache.org/jira/browse/PROTON-490 Project: Qpid Proton Issue Type: New Feature Components: python-binding Affects Versions: 0.6 Reporter: Ken Giusti Assignee: Ken Giusti Attachments: 47_proton-490_fix_cproton.i.patch, 47_proton-490_fix_import_statements_mllib_init.patch, 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, 47_proton-490_fix_mllib_transforms.py.patch, 47_proton-490_fix_print_encodings.h.py.patch, 47_proton-490_fix_print_protocol.h.py.patch, 47_proton-490_fix_proton_init.patch Attempting to link the Swig generated python bindings against the Python 3 development libraries produces unresolved symbol errors: CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes_dup': pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_message_get_user_id': pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_decimal128': pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_data_get_uuid': pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to `PyString_FromStringAndSize' CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): more undefined references to `PyString_FromStringAndSize' follow collect2: error: ld returned 1 exit status This is due to a name change in the Python 3 API: http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize http://docs.python.org/2/howto/cporting.html#conditional-compilation The wrapper C code in proton-c/bindings/python/python.i needs to be updated to support the Python 3 API. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: candidate commits for 0.9.1
On 04/27/2015 01:45 PM, Gordon Sim wrote: On 04/27/2015 01:14 PM, Rafael Schloming wrote: I also added PROTON-858 as a release blocker. I've been trying to get a fix proposal together for that. I'll post it for review as soon as I'm reasonably confident, still seeing some issues at present (not 100% sure they are related, but am assuming so). Just to update the status here. Although I have positive reviews for the simple patch, I have encountered some issues even with that during stress testing. I can't say for sure whether these are caused by my change as the test showing them up doesn't run long enough without the change. However until I know for sure I am not keen to commit it. If this is holding up things for the proton-j side, which after all is what motivated the release in the first place, I would suggest we continue without the fix for PROTON-858.
[jira] [Resolved] (PROTON-873) Convert use of Object.send to Object.__send__ for Ruby bindings
[ https://issues.apache.org/jira/browse/PROTON-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce resolved PROTON-873. - Resolution: Fixed Fix Version/s: 0.10 Convert use of Object.send to Object.__send__ for Ruby bindings --- Key: PROTON-873 URL: https://issues.apache.org/jira/browse/PROTON-873 Project: Qpid Proton Issue Type: Improvement Components: ruby-binding Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.10 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-871) IdleTimeoutTest#testTimeout engine test is not run against proton-j
[ https://issues.apache.org/jira/browse/PROTON-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14520046#comment-14520046 ] ASF subversion and git services commented on PROTON-871: Commit 57d6dcc7f73e77394cb2a01b1b1a089924ccee37 in qpid-proton's branch refs/heads/kgiusti-python3 from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=57d6dcc ] PROTON-871: implement the needed frame counting bits to stop the shim making the IdleTimeoutTest skip when run IdleTimeoutTest#testTimeout engine test is not run against proton-j --- Key: PROTON-871 URL: https://issues.apache.org/jira/browse/PROTON-871 Project: Qpid Proton Issue Type: Test Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 Support was added in 0.9 via PROTON-811 for idle-timeout handling in proton-j. There were some Java tests added that verify the functionality works, but the python equivalent engine test IdleTimeoutTest#testTimeout is skipped during execution. It is likely that the behavioural differences fixed for 0.9.1 in PROTON-843 would not have existed in 0.9 if the main python test was actually running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-344) Need Ruby version of msgr-send/msgr-recv tools
[ https://issues.apache.org/jira/browse/PROTON-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14520048#comment-14520048 ] ASF subversion and git services commented on PROTON-344: Commit 5f06462f37fa10d2da36e7755fa813c5b57986bd in qpid-proton's branch refs/heads/kgiusti-python3 from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5f06462 ] PROTON-344: Fix code not to trigger pedantic C++ warning Need Ruby version of msgr-send/msgr-recv tools -- Key: PROTON-344 URL: https://issues.apache.org/jira/browse/PROTON-344 Project: Qpid Proton Issue Type: Task Components: proton-c Affects Versions: 0.4 Reporter: Ken Giusti Assignee: Ken Giusti A ruby variant of msgr-send/recv traffic generators should be added to the soak tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
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
[VOTE]: Release Proton 0.9.1-rc1 as 0.9.1
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
[jira] [Created] (PROTON-872) Ruby Messenger should not use send as it conflicts with Ruby's Object::send method
Darryl L. Pierce created PROTON-872: --- Summary: Ruby Messenger should not use send as it conflicts with Ruby's Object::send method Key: PROTON-872 URL: https://issues.apache.org/jira/browse/PROTON-872 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.9 Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Ruby's Object class has a method named send that is used for programmatically invoking methods on an instance of a class. Classes should not use send but instead use a different name for such methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-872) Ruby Messenger should not use send as it conflicts with Ruby's Object::send method
[ https://issues.apache.org/jira/browse/PROTON-872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce resolved PROTON-872. - Resolution: Not A Problem Ruby doesn't recommend using send, so using that name should not be a concern. Ruby Messenger should not use send as it conflicts with Ruby's Object::send method -- Key: PROTON-872 URL: https://issues.apache.org/jira/browse/PROTON-872 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.9 Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Ruby's Object class has a method named send that is used for programmatically invoking methods on an instance of a class. Classes should not use send but instead use a different name for such methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: candidate commits for 0.9.1
On 04/29/2015 07:15 PM, Rafael Schloming wrote: On Wed, Apr 29, 2015 at 12:38 PM, Gordon Sim g...@redhat.com wrote: On 04/27/2015 01:45 PM, Gordon Sim wrote: On 04/27/2015 01:14 PM, Rafael Schloming wrote: I also added PROTON-858 as a release blocker. I've been trying to get a fix proposal together for that. I'll post it for review as soon as I'm reasonably confident, still seeing some issues at present (not 100% sure they are related, but am assuming so). Just to update the status here. Although I have positive reviews for the simple patch, I have encountered some issues even with that during stress testing. I can't say for sure whether these are caused by my change as the test showing them up doesn't run long enough without the change. However until I know for sure I am not keen to commit it. It sounds like the patch has at least improved things in your scenario. Do you think it's likely that the patch could have made things worse in some other way? I'm not sure at this stage. I can't see anything wrong with it, but I am seeing some odd things happening - current suspicion is that things (deliveries, perhaps sessions) are being 'finalized' when not expected. That could certainly be somehow related to the map impl.
Re: candidate commits for 0.9.1
On Wed, Apr 29, 2015 at 12:38 PM, Gordon Sim g...@redhat.com wrote: On 04/27/2015 01:45 PM, Gordon Sim wrote: On 04/27/2015 01:14 PM, Rafael Schloming wrote: I also added PROTON-858 as a release blocker. I've been trying to get a fix proposal together for that. I'll post it for review as soon as I'm reasonably confident, still seeing some issues at present (not 100% sure they are related, but am assuming so). Just to update the status here. Although I have positive reviews for the simple patch, I have encountered some issues even with that during stress testing. I can't say for sure whether these are caused by my change as the test showing them up doesn't run long enough without the change. However until I know for sure I am not keen to commit it. It sounds like the patch has at least improved things in your scenario. Do you think it's likely that the patch could have made things worse in some other way? --Rafael
[jira] [Commented] (PROTON-872) Ruby Messenger should not use send as it conflicts with Ruby's Object::send method
[ https://issues.apache.org/jira/browse/PROTON-872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14519918#comment-14519918 ] Darryl L. Pierce commented on PROTON-872: - Very good point. Thanks for the link, Rafi. I'll update the Reactive code to use __send__ instead of send. Ruby Messenger should not use send as it conflicts with Ruby's Object::send method -- Key: PROTON-872 URL: https://issues.apache.org/jira/browse/PROTON-872 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.9 Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Ruby's Object class has a method named send that is used for programmatically invoking methods on an instance of a class. Classes should not use send but instead use a different name for such methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
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'? --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
[GitHub] qpid-proton pull request: Initial transport frame size 256 bytes
GitHub user dcristoloveanu opened a pull request: https://github.com/apache/qpid-proton/pull/25 Initial transport frame size 256 bytes In order to reduce RAM footprint on rather simple scenarios on small devices the initial transport frame size could be lowered to 256, since the buffer is anyhow automatically enlarged if needed. Per earlier suggestions I created a config.h where parameters like this can go (the next candidate is the initial size for pn_data). If the need arises these parameters should be easily changeable in this case to match the platform need. You can merge this pull request into a Git repository by running: $ git pull https://github.com/dcristoloveanu/qpid-proton RAM-Transport-Frame-256-bytes Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/25.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 #25 commit 2158ef3447bab718cfa7b1cb9f9c635cb83beb7f Author: dcristoloveanu dcri...@microsoft.com Date: 2015-04-28T21:01:49Z Add config.h commit 65c6ce3df2c1c531cce49d2c3aab5f79f59c63bb Author: dcristoloveanu dcri...@microsoft.com Date: 2015-04-29T21:21:31Z -Added a configuration file named config.h where various parameters should be configurable (like transport initial frame buffer size, pnin the future _data initial size, etc.) -Set initial transport frame buffer size to 256 instead of 4K -Added config.h to the cmakelists.txt so that it shows up also in the Proton.sln Windows solution --- 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. ---
[GitHub] qpid-proton pull request: proton-c: minor code fixes
GitHub user dnwe opened a pull request: https://github.com/apache/qpid-proton/pull/26 proton-c: minor code fixes Prevent pn_data_vfill from peeking at memory outside the intended bounds and fix a few minor -Wextra warnings about incomplete struct initialisation You can merge this pull request into a Git repository by running: $ git pull https://github.com/dnwe/qpid-proton minor-fixes Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/26.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 #26 commit 4cfebeb02b8ab1da5cb98fa52bf0bca50903d4c9 Author: Dominic Evans dominic.ev...@uk.ibm.com Date: 2015-04-29T16:09:29Z NO-JIRA: prevent out-of-bounds memory access commit 83d9d2b545a1084813625049940fa47384173afc Author: Dominic Evans dominic.ev...@uk.ibm.com Date: 2015-04-29T18:04:32Z NO-JIRA: define pn_io_inspect as NULL commit ab83859058a23de93116a6544b1de4789470715b Author: Dominic Evans dominic.ev...@uk.ibm.com Date: 2015-04-29T18:06:46Z NO-JIRA: struct initialisation warning fixes --- 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. ---
[GitHub] qpid-proton pull request: proton-c: minor code fixes
Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/26#issuecomment-97600613  https://travis-ci.org/dnwe/qpid-proton/builds/60601702 --- 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. ---
