October 2010 - Boost - lists.preview.boost.org

Get PID from local socket?
by Rush Manbert 01 Nov '10

01 Nov '10

I am using boost ASIO to do socket communications between an app and a daemon running on the same machine. The communications go through a Unix Domain Socket on the Mac and a named pipe on Windows. I'm looking for a way that the client app could obtain the PID of the daemon process, starting with the connected socket. I have tried calling local_endpoint() and remote_endpoint(), but the only information there seems to be the socket path (at least on the Mac). My google searches have turned up nothing, and they actually suggest that there is no way to achieve this on the Mac, even if I were using the "normal" socket API. Does anyone know whether this is possible and how to do it? Thanks, Rush

2 1

[gsoc] Boost.Process done
by Boris Schaeling 31 Oct '10

31 Oct '10

Here are the results of the Boost.Process project within this year's Google Summer of Code program: We have a complete library to manage system processes now! If you like to play around with the library download the ZIP file from <http://www.highscore.de/boost/gsoc2010/process.zip>. As it's a header-only library simply copy the files to your Boost folder. If you like to quickly check the documentation click on <http://www.highscore.de/boost/gsoc2010/>. The library is now complete and basically ready for a review. As there have been so many Boost.Process drafts before (after all the first version was created 2006) this library's version number is 0.4. This will somehow make it possible to refer to the various drafts if it's necessary. For now I would appreciate if the library's test cases are run on as many platforms as possible. After copying the files from the ZIP file to the Boost folder change to libs/process/test/ and run bjam - that's all! What has been changed? * All previous Boost.Process drafts including Ilya's 2008 version from the vault have been thoroughly studied to create a better version. From the multiple Boost.Process drafts which have been floating around since 2006 we took the best ideas and created a new unified version. * The design and implementation of the library have been simplified. The library's API is smaller, and the implementation is easier to understand. It should be possible to benefit from this library as quickly as possible. Even developers who have no experience in managing system processes should be able to do so easily. * There are no POSIX and Windows specific classes anymore (posix_context, posix_child, win32_context, win32_child etc. have been dropped). Instead of trying to support each and every feature platforms provide extension points have been defined. They enable library users to "link in" those platform specific features they are interested in. * For the first time there is full support for synchronous and asynchronous operations. While asynchronous operations are built on top of Boost.Asio synchronous operations can be utilized without that library. Developers don't need to include any Boost.Asio headers and don't need to learn about Boost.Asio if they don't need asynchronous operations. * Stream behaviors define if and how standard streams can be used by a child process. While the various stream behaviors were defined as an enumeration or a boost::variant in previous Boost.Process drafts they are now implemented as classes. This makes it possible for developers to create new stream behaviors. * The code to start child processes on POSIX platforms has been carefully adapted to support multi-threaded applications (it turned out that this code was wrong in all Boost.Process drafts so far). The documentation explains what you need to take care of if you want to create child processes in a multi-threaded application on POSIX platforms. * The documentation is new and has been shortened and simplified. There is a user guide which can be read in 10 minutes and introduces all the major features of the library. The documentation is now also based on Quickbook. * The test cases have been restructured to simplify them. They can now be run without patching Boost.Test and without setting a path to a helper executable in the source files - it's now all automatic. They are all passed successfully with MSVC 9 (2008) and g++ 4.2.1. What is currently missing? * Pipelines are not (yet) supported. If you have been using boost::process::launch_pipeline() there is nothing in this Boost.Process draft you can use instead. Depending on feedback this feature will be added again (there was simply no time yet to do this). We hope that after four years, two Google Summer of Code programs and countless drafts this new version will finally become the official Boost.Process library so many have been waiting for. Boris and Felipe

18 182

[rational] PATCH: Use ordered_euclidean_ring_operators
by Mario Lang 30 Oct '10

30 Oct '10

Hi. Below is a patch which makes rational.hpp use grouped arithmetic operators. While we are at it, use ordered_euclidean_ring_operators instead of just ordered_field_operators. While it might sound strange at first, mod can make sense even for rational numbers. For instance, Common Lisp, which has a native rational type, works fine if mod is used on rational numbers... template <typename IntType> rational<IntType>& rational<IntType>::operator%= (const rational<IntType>& r) { return *this -= r * floor(rational_cast<double>(*this / r)); } I am aware that the use of floor() is probably problematic. I am all open for comments and suggestions for improvements. -- Thanks, ⡍⠁⠗⠊⠕

1 0

[graph] PATCH to eliminate gcc 4.2 warnings when compiling boost/graph/read_dimacs.hpp
by Daniel Trebbien 30 Oct '10

30 Oct '10

Attached is a patch that changes the definition of `err_message` in boost/graph/read_dimacs.hpp@66260 from: static char *err_message[] to: static const char *err_message[] This will eliminate the warnings that were recorded at: http://www.boost.org/development/tests/trunk/developer/output/Sandia-gcc-4-… Daniel

2 1

Is it time for another bug sprint? (Post 1.45 release, I mean)
by Marshall Clow 30 Oct '10

30 Oct '10

What do people think? -- Marshall

11 17

[regex] Disabling ICU check when building with bjam, 1.44
by Cliff Green 30 Oct '10

30 Oct '10

This is on Boost 1.44, g++ 4.1.2 on Linux (RHEL 5.x, can't remember the x at the moment), although it applies generally to building regex. I can't find a way to easily "disable" the "ICU installed" check and resulting functionality / build. I chatted on IRC, and the only way some (experienced Boost) developers could come up with was to change: alias icu_options : : : : [ check-target-builds has_icu : $(ICU_OPTS) : ] ; to alias icu_options : : : : ; in Jamfile.v2. My situation / use case: Our build system has ICU installed. Our deployment system has exactly the same OS and runtime environment, except that the ICU package is not installed. I would like to build regex without the "check that ICU is installed to determine whether the enable ICU" logic in the jamfiles. The regex documentation has an: "-sHAVE_ICU=1" example, but "-sHAVE_ICU=0" doesn't work, and tracing through the jamfiles / boost build I couldn't find where that option is honored / processed. There's also a BOOST_HAS_ICU macro that is defined or undefined in various ways, but adding define=BOOST_HAS_ICU 0 to bjam also didn't appear to do anything (and I tried some other ways to undefine BOOST_HAS_ICU, including in the jamfile, but nothing seemed to work). The docs also mention that the default is to not enable / build with ICU, but that doesn't seem to be the case (with 1.44). (From the first line of ICU build section: "A default build of this library does not enable Unicode support via ICU. There is no need to enable ... ".) So I'm confused (as well as some other regulars on IRC), and either the documentation needs updating, jamfiles need updating, or my understanding needs updating. For now, the workaround mentioned above works fine, and the resulting regex.so file does not have any ICU external library dependencies (which is what is desired for our deployment environment). Thanks! Cliff

2 2

[assign] list_inserter regression test failure on VC10 / release branch
by Richard Webb 30 Oct '10

30 Oct '10

Another minor regression test fix: The list_inserter regression test (libs\assign\test\list_inserter.cpp) was fixed for VC10 on the Trunk in revision 62737, but hasn't yet been merged to the release branch. (the change also fixes one of the errors from GCC/C++0x, but the test still fails for other reasons).

1 0

[1.45] Beta next week?
by Beman Dawes 30 Oct '10

30 Oct '10

I've been too busy to do much on 1.45, but don't see any reason we can't get a beta out next week more or less as scheduled. If anyone know of any showstoppers, please let us know what the problem is. Thanks, --Beman

11 35

[mpl] anyone fancy merging the for_each test to the release branch?
by Richard Webb 29 Oct '10

29 Oct '10

Does anyone feel like merging libs/mpl/test/for_each.cpp (revision 65167) to the release branch? It's only a minor change to the test itself, but it clears a failure on VC10 and various C++0x GCCs.

3 2

[quickbook] Code links not working
by Edward Diener 29 Oct '10

29 Oct '10

I can not seem to get the quickbook code links to work. Nothing is being generated from the code link. As an example, to test them out I have in quickbook: This is a test of a macro reference - [macroref VMD_DATA_SIZE Test Macro reference] . and in my doxygen generated XML I see: <library-reference id="variadic_macro_data_reference"> <title>Variadic Macro Data Reference </title> <header name="boost/variadic_macro_data/VariadicMacroData.hpp"> <macro name="VMD_DATA_SIZE" kind="functionlike"> etc. but the output shows: This is a test of a macro reference - . Any ideas to get this to work would be appreciated.

12 20