[jira] [Assigned] (PROTON-176) Provide a unit test framework for the Perl bindings
[ https://issues.apache.org/jira/browse/PROTON-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce reassigned PROTON-176: --- Assignee: Darryl L. Pierce Provide a unit test framework for the Perl bindings --- Key: PROTON-176 URL: https://issues.apache.org/jira/browse/PROTON-176 Project: Qpid Proton Issue Type: Test Components: proton-c Affects Versions: 0.3 Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Provide unit tests to verify the code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Perl language bindings are now pushed...
On Wed, Dec 5, 2012 at 8:18 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Tue, Dec 04, 2012 at 05:24:25PM -0500, Andrew Stitcher wrote: On Thu, 2012-11-29 at 17:16 -0500, Darryl L. Pierce wrote: I've pushed the Perl language bindings as well as the send/recv examples for using the qpid::proton::Messenger and qpid::proton::Message classes. These changes break make install for a developer build installing in a non system location: ... -- Installing: /home/andrew/Work/proton/install/lib64/python2.7/site-packages/proton.pyo -- Installing: /home/andrew/Work/proton/install/lib64/python2.7/site-packages/_cproton.so -- Removed runtime path from /home/andrew/Work/proton/install/lib64/python2.7/site-packages/_cproton.so -- Installing: /home/andrew/Work/proton/install/lib64/ruby/cproton.so -- Removed runtime path from /home/andrew/Work/proton/install/lib64/ruby/cproton.so -- Installing: /usr/lib64/perl5/libcproton_perl.so CMake Error at bindings/perl/cmake_install.cmake:44 (FILE): file INSTALL cannot copy file /home/andrew/Work/proton/bld/bindings/perl/libcproton_perl.so to /usr/lib64/perl5/libcproton_perl.so. Call Stack (most recent call first): bindings/cmake_install.cmake:39 (INCLUDE) cmake_install.cmake:137 (INCLUDE) It seems like this new stuff just ignores CMAKE_INSTALL_PREFIX. Yeah, it appears that the CMake configuration for Proton doesn't do what Qpid's configuration did as far as prepending the install prefix to directories. None of our language bindings seem to be doing this in Proton. The other builds don't manually prepend the install prefix, however they still honor it where appropriate by using relative paths. Cmake will automatically prepend the install prefix for you if you just use a relative path. I'm not sure why the qpid build goes to the trouble of manually prepending it. IMHO that's a bit misleading as you generally only need to use absolute paths if you're trying to install something outside of the install root. --Rafael
[jira] [Created] (PROTON-177) Perl bindings do no honor the install prefix
Darryl L. Pierce created PROTON-177: --- Summary: Perl bindings do no honor the install prefix Key: PROTON-177 URL: https://issues.apache.org/jira/browse/PROTON-177 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.3 Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce When the Perl bindings are installed, they do so the patch specified by the FindPerl and FindPerlLibrary modules. They should include any specified install prefix for developers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-178) PHP bindings do not honor the install prefix
Darryl L. Pierce created PROTON-178: --- Summary: PHP bindings do not honor the install prefix Key: PROTON-178 URL: https://issues.apache.org/jira/browse/PROTON-178 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Darryl L. Pierce When installing in a development environment, the system still attempts to install the PHP bindings in the default location rather than honoring the install prefix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Perl language bindings are now pushed...
On Wed, Dec 05, 2012 at 08:18:06AM -0500, Darryl L. Pierce wrote: It seems like this new stuff just ignores CMAKE_INSTALL_PREFIX. Yeah, it appears that the CMake configuration for Proton doesn't do what Qpid's configuration did as far as prepending the install prefix to directories. None of our language bindings seem to be doing this in Proton. More specifically, PHP is doing the same as Perl and not honoring the install prefix. I've modified the Perl CMake environment to correct this behavior. But the PHP bindings are giving me a particular pain. Specifically, the INI directory. Is there a good example of how to set the prefix? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpanK6wCjVxC.pgp Description: PGP signature
Re: Perl language bindings are now pushed...
On Wed, Dec 05, 2012 at 08:55:32AM -0500, Rafael Schloming wrote: The other builds don't manually prepend the install prefix, however they still honor it where appropriate by using relative paths. Cmake will automatically prepend the install prefix for you if you just use a relative path. I'm not sure why the qpid build goes to the trouble of manually prepending it. IMHO that's a bit misleading as you generally only need to use absolute paths if you're trying to install something outside of the install root. The Python bindings using the value returned by: python -c from distutils.sysconfig import get_python_lib; print get_python_lib(True, prefix='') which returns a relative path. Perl uses: perl -V:installarchlib which returns an absolute patch. So we're going to have to monkey with the path in the Perl case, either by removing the leading / on *nix (and whatever is necessary on Windows), or else continue to manually find the prefix [1] and replace it, which is what we're now doing. [1] perl -V:installprefix -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpCL6P5HxByk.pgp Description: PGP signature
[jira] [Updated] (PROTON-172) Implement SSL within proton-j
[ https://issues.apache.org/jira/browse/PROTON-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-172: - Attachment: (was: 0001-PROTON-172-refactored-Java-SSL-implementation-to-mak.patch) Implement SSL within proton-j - Key: PROTON-172 URL: https://issues.apache.org/jira/browse/PROTON-172 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Philip Harvey Assignee: Keith Wall Attachments: 0001-PROTON-172-Java-SSL-implementation-enable-system-tes.patch, 0002-PROTON-172-Extra-tests-and-enhanced-pump-method.patch Implement SSL within proton-j -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-172) Implement SSL within proton-j
[ https://issues.apache.org/jira/browse/PROTON-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-172: - Attachment: 0002-PROTON-172-Moved-SSL-classes-into-package-org.engine.patch 0001-PROTON-172-refactored-Java-SSL-implementation-to-mak.patch refactored SSL implementation - extracted most byte buffer manipulation to improve readability. The second patch is only a package-move of the SSL classes into their own package, and a couple of visibility changes to PlainTransportWrapper and SslImpl.wrap to allow this. Implement SSL within proton-j - Key: PROTON-172 URL: https://issues.apache.org/jira/browse/PROTON-172 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Philip Harvey Assignee: Keith Wall Attachments: 0001-PROTON-172-Java-SSL-implementation-enable-system-tes.patch, 0001-PROTON-172-refactored-Java-SSL-implementation-to-mak.patch, 0002-PROTON-172-Extra-tests-and-enhanced-pump-method.patch, 0002-PROTON-172-Moved-SSL-classes-into-package-org.engine.patch Implement SSL within proton-j -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-179) proton-j - replace system.out and system.err calls with java.util.logging
Philip Harvey created PROTON-179: Summary: proton-j - replace system.out and system.err calls with java.util.logging Key: PROTON-179 URL: https://issues.apache.org/jira/browse/PROTON-179 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.2 Reporter: Philip Harvey Assignee: Philip Harvey We do not yet know what the final solution is for how proton-j should perform logging. We think we might want to allow Proton's host application to provide logging callbacks, allowing Proton's output to be combined with the host application's output. Pending the final logging design, we should use java.util.logging in the mean time. This is at least preferable to the existing system.out.println calls. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-179) proton-j - replace system.out and system.err calls with java.util.logging
[ https://issues.apache.org/jira/browse/PROTON-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated PROTON-179: - Attachment: 0001-PROTON-179-use-java.util.logging-instead-of-system.o.patch attached patch. Should be applied AFTER the patches in PROTON-172. proton-j - replace system.out and system.err calls with java.util.logging - Key: PROTON-179 URL: https://issues.apache.org/jira/browse/PROTON-179 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.2 Reporter: Philip Harvey Assignee: Philip Harvey Attachments: 0001-PROTON-179-use-java.util.logging-instead-of-system.o.patch We do not yet know what the final solution is for how proton-j should perform logging. We think we might want to allow Proton's host application to provide logging callbacks, allowing Proton's output to be combined with the host application's output. Pending the final logging design, we should use java.util.logging in the mean time. This is at least preferable to the existing system.out.println calls. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PROTON-179) proton-j - replace system.out and system.err calls with java.util.logging
[ https://issues.apache.org/jira/browse/PROTON-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned PROTON-179: Assignee: Rob Godfrey (was: Philip Harvey) hi Rob, pls could you review and commit if you're happy proton-j - replace system.out and system.err calls with java.util.logging - Key: PROTON-179 URL: https://issues.apache.org/jira/browse/PROTON-179 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.2 Reporter: Philip Harvey Assignee: Rob Godfrey Attachments: 0001-PROTON-179-use-java.util.logging-instead-of-system.o.patch We do not yet know what the final solution is for how proton-j should perform logging. We think we might want to allow Proton's host application to provide logging callbacks, allowing Proton's output to be combined with the host application's output. Pending the final logging design, we should use java.util.logging in the mean time. This is at least preferable to the existing system.out.println calls. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-136) Add support for SSL session resumption
[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510620#comment-13510620 ] Philip Harvey commented on PROTON-136: -- Thanks Ken, I was planning to look at this today but got delayed by some proton-c / Swig / Python problems. Will take a look tomorrow. Add support for SSL session resumption -- Key: PROTON-136 URL: https://issues.apache.org/jira/browse/PROTON-136 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.3 Reporter: Affan Dar Assignee: Ken Giusti Labels: ssl, sslContext, sslresume Open SSL supports resumption of SSL sessions which by-pass the heavy SSL handshake process. This is critical for scenarios involving low powered devices especially on cellular data networks where bandwidth is precious. It would be great if Proton exposes this ssl resume feature to users. . From: rhs [mailto:rschlom...@gmail.com] Sent: Tuesday, November 13, 2012 11:34 AM To: Affan Dar Cc: David Ingham Subject: Re: SSL session resumption On Tue, Nov 13, 2012 at 8:05 PM, Affan Dar affan...@microsoft.com wrote: Serializing/restoring the whole session state for the messenger will work for the scenario I think. Ok, let's start with this step then. I'm open to providing something finer grained if there is a need, but my preference is to keep it simple for the moment. One more thing, RFC 5077 has another flavor of session resumption which openssl supports (original implemented as RFC 4057 back in 2007 I think). This allows us to resume sessions without carrying state on the server side which as you can imagine is a big deal for service vendors. Probably there is no API level impact if messenger handles the session state itself but just wanted to put this on your radar. Ok, good to know. Could one of you file a JIRA for this upstream? I'm trying to get things a little more organized on the process front and keep everything centralized in JIRA. ;-) --Rafael -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Perl language bindings are now pushed...
On Wed, Dec 05, 2012 at 11:12:02AM -0500, Rafael Schloming wrote: On Wed, Dec 5, 2012 at 9:52 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, Dec 05, 2012 at 08:18:06AM -0500, Darryl L. Pierce wrote: It seems like this new stuff just ignores CMAKE_INSTALL_PREFIX. Yeah, it appears that the CMake configuration for Proton doesn't do what Qpid's configuration did as far as prepending the install prefix to directories. None of our language bindings seem to be doing this in Proton. More specifically, PHP is doing the same as Perl and not honoring the install prefix. I've modified the Perl CMake environment to correct this behavior. But the PHP bindings are giving me a particular pain. Specifically, the INI directory. Is there a good example of how to set the prefix? The PHP bindings do honor the install prefix, just possibly not in the way you're thinking. The PHP bindings build provides a number of user visible configuration options to explicitly control install locations, e.g.: PHP_EXT_DIR, PHP_INCLUDE_DIR, PHP_INI_DIR, etc If you set these locations to a relative path then the build will install relative to the CMAKE_INSTALL_PREFIX. The *default* values for these locations are created by interrogating the PHP install that the binding is built against. Okay, then a developer has to explicitly override the INI directory each time. For the EXT and INCLUDE directories it's easy to do what we're doing in Perl now to override the prefix. That feels a little clumsy to me since I don't really want to have to specify it each time I do a build. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpLulMisDZuA.pgp Description: PGP signature
Re: Perl language bindings are now pushed...
On Wed, 2012-12-05 at 11:12 -0500, Rafael Schloming wrote: On Wed, Dec 5, 2012 at 9:52 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, Dec 05, 2012 at 08:18:06AM -0500, Darryl L. Pierce wrote: It seems like this new stuff just ignores CMAKE_INSTALL_PREFIX. Yeah, it appears that the CMake configuration for Proton doesn't do what Qpid's configuration did as far as prepending the install prefix to directories. None of our language bindings seem to be doing this in Proton. More specifically, PHP is doing the same as Perl and not honoring the install prefix. I've modified the Perl CMake environment to correct this behavior. But the PHP bindings are giving me a particular pain. Specifically, the INI directory. Is there a good example of how to set the prefix? The PHP bindings do honor the install prefix, just possibly not in the way you're thinking. The PHP bindings build provides a number of user visible configuration options to explicitly control install locations, e.g.: PHP_EXT_DIR, PHP_INCLUDE_DIR, PHP_INI_DIR, etc If you set these locations to a relative path then the build will install relative to the CMAKE_INSTALL_PREFIX. The *default* values for these locations are created by interrogating the PHP install that the binding is built against. I disagree, I'd say that the PHP make install is equally broken. When you interrogate php-config you should also get the installation prefix[1] and then subtract it, just like with the other bindings. [Darryl, thanks for fixing the perl make install] Andrew [1] Use php-config --prefix
[jira] [Resolved] (PROTON-178) PHP bindings do not honor the install prefix
[ https://issues.apache.org/jira/browse/PROTON-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce resolved PROTON-178. - Resolution: Fixed Fix Version/s: 0.3 PHP bindings do not honor the install prefix Key: PROTON-178 URL: https://issues.apache.org/jira/browse/PROTON-178 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Darryl L. Pierce Fix For: 0.3 When installing in a development environment, the system still attempts to install the PHP bindings in the default location rather than honoring the install prefix. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SSL related noise in tests? (was Re: Proton 0.3 ETA?)
Yep, this has been addressed in PROTON-179. On Dec 5, 2012 2:44 PM, Rob Godfrey rob.j.godf...@gmail.com wrote: Yes - I'm sure Phil is working on a patch to remove this, the longer term solution being to add some sort of cross-platform logging support -- Rob On 5 December 2012 15:40, Gordon Sim g...@redhat.com wrote: On 12/05/2012 01:56 PM, Gordon Sim wrote: On 12/05/2012 01:09 PM, Hiram Chirino wrote: We getting closer? I would like to start cutting release candidates for ActiveMQ and I can't do that until proton-j is released. I'd like to get the messenger API and implementation in before we do that. My plan was to try and add in the acknowledgement support that was added to the C version and then check it all in. If I don't have time for that, then I would at least check in what is ready now. BTW, I'm seeing lots of 'noise' printed to the console when running the proton-j tests. They seem to all be related to SSL. Is this a known issue? --**--**- To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.**org dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Perl language bindings are now pushed...
On Wed, Dec 5, 2012 at 2:50 PM, Andrew Stitcher astitc...@redhat.comwrote: On Wed, 2012-12-05 at 11:12 -0500, Rafael Schloming wrote: On Wed, Dec 5, 2012 at 9:52 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, Dec 05, 2012 at 08:18:06AM -0500, Darryl L. Pierce wrote: It seems like this new stuff just ignores CMAKE_INSTALL_PREFIX. Yeah, it appears that the CMake configuration for Proton doesn't do what Qpid's configuration did as far as prepending the install prefix to directories. None of our language bindings seem to be doing this in Proton. More specifically, PHP is doing the same as Perl and not honoring the install prefix. I've modified the Perl CMake environment to correct this behavior. But the PHP bindings are giving me a particular pain. Specifically, the INI directory. Is there a good example of how to set the prefix? The PHP bindings do honor the install prefix, just possibly not in the way you're thinking. The PHP bindings build provides a number of user visible configuration options to explicitly control install locations, e.g.: PHP_EXT_DIR, PHP_INCLUDE_DIR, PHP_INI_DIR, etc If you set these locations to a relative path then the build will install relative to the CMAKE_INSTALL_PREFIX. The *default* values for these locations are created by interrogating the PHP install that the binding is built against. I disagree, I'd say that the PHP make install is equally broken. When you interrogate php-config you should also get the installation prefix[1] and then subtract it, just like with the other bindings. I don't see why this is desirable, this just makes the overall build broken if you ever choose a prefix that is different from that reported by php. I think the correct thing to do is default to installing extension modules in the system configured directories, but allow people (experts really) to override that behaviour if they choose to. --Rafael
[jira] [Resolved] (PROTON-168) Support for building on OS X
[ https://issues.apache.org/jira/browse/PROTON-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-168. Resolution: Fixed Fix Version/s: 0.3 Assignee: Andrew Stitcher I've checked in changes that should fix all the relevant issues now, so proton should now compile under OS X Support for building on OS X Key: PROTON-168 URL: https://issues.apache.org/jira/browse/PROTON-168 Project: Qpid Proton Issue Type: New Feature Components: proton-c Environment: Mac OS X Lion Reporter: Andy Goldstein Assignee: Andrew Stitcher Priority: Minor Fix For: 0.3 Attachments: build.log, clock.patch, deprecate-pragma.patch, nowerror.patch, proton-168.patch, PROTON-168-v2.patch, SO_NOSIGPIPE.patch I did some quick hacky work to get proton-c to compile on my Mac running Lion. I also have homebrew installed and use that to supply any libraries that are necessary but not included by default on the Mac. I'm attaching my quick patch, and it would be great if someone could take it and update it so it's more robust and commit-quality :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-104) OS X: Don't link uuid
[ https://issues.apache.org/jira/browse/PROTON-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-104. Resolution: Fixed Fix Version/s: 0.3 Assignee: Andrew Stitcher OS X: Don't link uuid - Key: PROTON-104 URL: https://issues.apache.org/jira/browse/PROTON-104 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Hiram Chirino Assignee: Andrew Stitcher Fix For: 0.3 Don't link uuid lib on OX, it does not exist / is part the clib. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-105) OS X: Build has warnings, cause build failures
[ https://issues.apache.org/jira/browse/PROTON-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-105. Resolution: Fixed Fix Version/s: 0.3 Assignee: Andrew Stitcher This has been fixed by making warnings as errors configurable and turned off by default on OS X OS X: Build has warnings, cause build failures -- Key: PROTON-105 URL: https://issues.apache.org/jira/browse/PROTON-105 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Hiram Chirino Assignee: Andrew Stitcher Fix For: 0.3 Perhaps you '-Werror -pedantic-errors' should be removed from the build options for the OS X build. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-106) OS X: MSG_NOSIGNAL does not exist
[ https://issues.apache.org/jira/browse/PROTON-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-106. Resolution: Fixed Fix Version/s: 0.3 Assignee: Andrew Stitcher This is fixed by making the build use either MSG_NOSIGNAL or SO_NOSIGPIPE depending on what is available. OS X: MSG_NOSIGNAL does not exist - Key: PROTON-106 URL: https://issues.apache.org/jira/browse/PROTON-106 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Hiram Chirino Assignee: Andrew Stitcher Fix For: 0.3 MSG_NOSIGNAL is used in proton-c/src/driver.c but it does not exist on OS X. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Some proton portability work.
I've committed some portability work on proton today. At this point, proton should configure and compile without error on FreeBSD and MacOS X. I've also done a bit of work which improves compilation under gcc on Solaris too, but this isn't finished (Solaris is missing any functionality to easily ignore SIGPIPE when writing to closed sockets). I've also done a bit of work to get it cross compile under mingw32, but again there are some remaining issues (ignoring the fact that the driver code for Windows isn't finished anyway) Questions, bugs etc. to me Andrew
Re: Some proton portability work.
Looks good on OSX 10.8.2 Compilation is fine, send/recv work fine as well. -W On Dec 5, 2012, at 5:04 PM, Andrew Stitcher astitc...@redhat.com wrote: I've committed some portability work on proton today. At this point, proton should configure and compile without error on FreeBSD and MacOS X. I've also done a bit of work which improves compilation under gcc on Solaris too, but this isn't finished (Solaris is missing any functionality to easily ignore SIGPIPE when writing to closed sockets). I've also done a bit of work to get it cross compile under mingw32, but again there are some remaining issues (ignoring the fact that the driver code for Windows isn't finished anyway) Questions, bugs etc. to me Andrew
[jira] [Commented] (PROTON-121) Platform specific code is mixed in with platform independent code
[ https://issues.apache.org/jira/browse/PROTON-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510835#comment-13510835 ] Andrew Stitcher commented on PROTON-121: A good (perhaps the only) example of this is the use of ntohl() in the engine code. ntohl() is part of the BSD sockets API and not defined in ANSI C at all. Platform specific code is mixed in with platform independent code - Key: PROTON-121 URL: https://issues.apache.org/jira/browse/PROTON-121 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Andrew Stitcher the function pn_error_from errno() is platform specific and so should not be in error.c which is (everywhere else) purely platform independent. It should be moved to a platform (POSIX) specific file (perhaps a file with only this single function). [The clue for this is the #define POSIX_C_SOURCE at the top of error.c] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-121) Platform specific code is mixed in with platform independent code
[ https://issues.apache.org/jira/browse/PROTON-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510841#comment-13510841 ] Andrew Stitcher commented on PROTON-121: Another example is the use of strcasecmp() which again is not part of ANSI C. Platform specific code is mixed in with platform independent code - Key: PROTON-121 URL: https://issues.apache.org/jira/browse/PROTON-121 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Andrew Stitcher the function pn_error_from errno() is platform specific and so should not be in error.c which is (everywhere else) purely platform independent. It should be moved to a platform (POSIX) specific file (perhaps a file with only this single function). [The clue for this is the #define POSIX_C_SOURCE at the top of error.c] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Some proton portability work.
+1 Good stuff all around. On Dec 5, 2012, at 5:27 PM, William Henry whe...@redhat.com wrote: Excellent work Andrew. William On Dec 5, 2012, at 5:04 PM, Andrew Stitcher astitc...@redhat.com wrote: I've committed some portability work on proton today. At this point, proton should configure and compile without error on FreeBSD and MacOS X. I've also done a bit of work which improves compilation under gcc on Solaris too, but this isn't finished (Solaris is missing any functionality to easily ignore SIGPIPE when writing to closed sockets). I've also done a bit of work to get it cross compile under mingw32, but again there are some remaining issues (ignoring the fact that the driver code for Windows isn't finished anyway) Questions, bugs etc. to me Andrew
RE: Some proton portability work.
What is planned for the driver code for Windows? Maybe I could help. I have a Windows port running and could put more patches in Jira for changes to the driver code required by Windows. Thanks, Mary Hinton -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: Wednesday, December 05, 2012 5:04 PM To: proton Subject: Some proton portability work. I've committed some portability work on proton today. At this point, proton should configure and compile without error on FreeBSD and MacOS X. I've also done a bit of work which improves compilation under gcc on Solaris too, but this isn't finished (Solaris is missing any functionality to easily ignore SIGPIPE when writing to closed sockets). I've also done a bit of work to get it cross compile under mingw32, but again there are some remaining issues (ignoring the fact that the driver code for Windows isn't finished anyway) Questions, bugs etc. to me Andrew
Re: Perl language bindings are now pushed...
On Wed, Dec 5, 2012 at 4:38 PM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, Dec 05, 2012 at 03:08:24PM -0500, Rafael Schloming wrote: Okay, then a developer has to explicitly override the INI directory each time. For the EXT and INCLUDE directories it's easy to do what we're doing in Perl now to override the prefix. That feels a little clumsy to me since I don't really want to have to specify it each time I do a build. I'm not sure I follow you. These are all configured variables. You only ever have to set any of them once. To keep things from lingering, each time I do a build I go into my OOT build directory and do: rm -rf * cmake ../proton-c I don't want to have to specify the PHP_INI_DIR when I do the above. I suppose I could have an alias defined for it (maybe have config.sh source a separate, non-versioned file containing developer aliases?). But that could very well gum up the plumbing. :) You may not have to. It's not necessary for building, only if you want to do a make install. I suppose my usage isn't quite the same as what Andrew mentioned. For me, I don't install to non-standard places, so my above scenario won't be affected. IOW, I don't do make install and run from those installed pieces and instead run against things in my CPROTON_BUILD directory. I guess for a developer who's doing as Andrew mentioned, they'll have to override PHP_INI_DIR when they install, which should be less frequent than my in-place builds. So the main point of this stuff is to make proton easy to install for users. I'm all for making our lives as developers easier, but not at the expense of users, and I think not having the bindings behave as I've described will significantly complicates things for users. Imagine a system with python installed in /usr, and perl and php both installed in /usr/local. Say a user wants to install proton and the relevant bindings onto this system. If all the bindings default their location based on interrogating the installed interpreters, this is easy. The user can choose to install proton itself into either /usr or /usr/local, and all the bindings will just go into the right place. Now consider what happens if we automatically munge the prefix. There really isn't a good way to explain to a user how to install on this system. They either need to choose to put proton into /usr and munge their perl and php installs to look for extensions under /usr as well as /usr/local, or possibly somehow override undocumented variables in the cmake build to get the extension modules into the right place. I don't even know if this is possible as the overridden variables might well be munged. I think this scenario really points to two issues (1) the defaults really should be based on interrogation of the interpreters that the bindings are built against if we want a robust and simple README file, and (2) all the bindings should support proper manual overriding of the installed location of each binding. I believe (2) is only the case for the PHP binding currently, or at least it was the case before the php binding was modified to do the munging. Unless I'm missing something, I'd like to suggest we rollback that change and make the other bindings match the PHP behaviour of defaulting based on interrogation and providing proper configuration variables for manual override. I'm aware this might make certain developer scenarios mildly more onereous, but with manual overrides in place they should all be possible, and I believe the benefit for users is significant. --Rafael
RE: Some proton portability work.
That sounds good. -Original Message- From: Cliff Jansen [mailto:cliffjan...@gmail.com] Sent: Wednesday, December 05, 2012 6:33 PM To: proton@qpid.apache.org Subject: Re: Some proton portability work. Hi Mary, Unless you have a problem with the driver in https://reviews.apache.org/r/6302/ I was just about to dust that off (update it and/or pull in your github work) and work it in parallel with proton-159. In theory the 2 together should result in proton working with C++ and Windows libraries. The additional steps to get a Visual Studio implementation should be very straight forward after that. As before, the intent is to get a functional driver (without ssl for now) that can get people going on Windows. A high performance driver (with overlapped io presumably) and with ssl integration would follow later. Cliff On Wed, Dec 5, 2012 at 2:45 PM, Mary Hinton m.hin...@nc.rr.com wrote: What is planned for the driver code for Windows? Maybe I could help. I have a Windows port running and could put more patches in Jira for changes to the driver code required by Windows. Thanks, Mary Hinton -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: Wednesday, December 05, 2012 5:04 PM To: proton Subject: Some proton portability work. I've committed some portability work on proton today. At this point, proton should configure and compile without error on FreeBSD and MacOS X. I've also done a bit of work which improves compilation under gcc on Solaris too, but this isn't finished (Solaris is missing any functionality to easily ignore SIGPIPE when writing to closed sockets). I've also done a bit of work to get it cross compile under mingw32, but again there are some remaining issues (ignoring the fact that the driver code for Windows isn't finished anyway) Questions, bugs etc. to me Andrew
