- Boost - lists.boost.org

Which libraries on the review schedule are ready for review?
by vicente.botet 21 Feb '11

21 Feb '11

Hi, I would like the authors of the libraries on the review schedule state clearly if his libraries are ready for review. Lexer Ben Hanson - Eric Niebler - Shifted Pointer Phil Bouchard - Needed - Logging John Torjo - Gennadiy Rozental - Join Yigong Liu - Needed - Pimpl Vladimir Batov - Needed - Task Oliver Kowalke - Vicente Botet - Endian Beman Dawes - Needed - Conversion Vicente Botet - Needed - Sorting Steven Ross - Needed - AutoBuffer Thorsten Ottosen - Robert Stewart - String Convert Vladimir Batov - Needed - Containers Ion Gaztañaga - Needed - Type Traits Extensions Frédéric Bron - Joel Falcou - Interthreads Vicente Botet - Needed - Bitfield Vicente Botet - Needed - Lockfree Tim Blechmann - Needed - Fiber Oliver Kowalke - Needed - Creasing (Sequence Properties) Grant Erickson - Needed - Static Size Linear Algebra Emil Dotchevski - Needed - Locale Artyom Beilis - Needed - XInt Chad Nelson - Needed - Context Oliver Kowalke - Needed - Stopwatches Vicente Botet - Anthony Williams - Please could you replay to this mail for each one of your libraries? Thanks, Vicente

13 36

[1.46.0] Release candidates available
by Beman Dawes 21 Feb '11

21 Feb '11

Release candidate files for the 1.46.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure. This helps ensure the candidates build OK before we push them out to SourceForge. Thanks, --The release managers

9 13

Re: [boost] Formal Review of Proposed Boost.Process library
by Max Sobolev 21 Feb '11

21 Feb '11

(First, please, excuse me for my "english".) This variant of the Boost.Process library should NOT (--never--) be accepted. The Boost.Process must be implemented as a DSEL (probably through the Boost.Proto expression templates framework) with a nice (commonly known) syntax like: using boost::process; using process::arg; namespace fs = boost::filesystem; process ls("ls"), grep("grep"); fs::path libs = "/usr/lib"; auto pipe = ls [--arg("reverse") % -arg('l') % libs] | grep ["^d"]; run(pipe); // or: // pipe(); // or: // ls(); This approach provide a declarative, not an imperative programming style. (A lot of work done by expression templates' inner mechanics.) The library must support: * i/o redirection * process piping; [implicit pipes] * named/unnamed pipe objects; [explicit pipes] * runned processes surfing (boost::process::processes_iterator): - CreateToolhelp32Snapshot()/Process32First()/Process32Next() API functions in Windows - /proc filesystem parsing in linux/some unix * loaded shared libraries surfing (boost::process::modules_iterator): - CreateToolhelp32Snapshot()/Module32First()/Module32Next() API functions in Windows - /proc filesystem parsing in linux/some unix * child processes surfing (boost::process::children_iterator) - parsing processes_iterator's range results - /proc filesystem parsing in linux/(perhaps) some unix - empty iterator range by default * runned thread per process surfing (boost::process::threads_iterator) - filtered results of CreateToolhelp32Snapshot()/Thread32First()/Thread32Next() API functions in Windows - /proc filesystem parsing in linux (see /proc/[pid]/task filesystem branch since linux 2.6.0-test6) - empty iterator range by default * runned thread surfing (boost::threads_iterator) - CreateToolhelp32Snapshot()/Thread32First()/Thread32Next() API functions in Windows - FOR-EACH process IN system: back_inserter(boost::process::threads_iterator(process), boost::process::threads_iterator(), threads); * (any) process stats * process creation * daemonization - through Service API on Windows * process security and privacy aspects (probably this is subject for an another separate library, part of which must be integrated with the Boost.Process) _________________________________ More examples: using boost::process; using process::arg; using process::env; namespace fs = boost::filesystem; // echo $PATH # (%PATH% in Windows) process("echo") [env("PATH")] (); // or: run(process("echo") [env("PATH")]); // ps -aux > ps.out process ps("ps"); run(ps [-arg('a', 'u', 'x')] > "ps.out"); process::_this_ > "file.out" < "file.in"; // probably static_assert() on Windows platform process::_this_ >> "file.out" < "file.in"; std::cin >> ...; // read from "file.in" std::cout << ...; // write to "file.out" // grep -i -n searched_word file.in > file.out: process grep("grep"); run( grep [-arg('i') % -arg('n') % "searched_word" % "file.in"] > "file.out"); // cat /etc/rc.d/xinetd | grep -v '^#' | sed '/^$/d' > file.out process cat("cat"), grep("grep"), sed("sed"); fs::path conf("/etc/rc.d/xinetd"); auto pipe = cat [conf] | grep [-arg('v') % "^#"] | sed ["/^$/d"] > "file.out"; pipe(); using namespace process::placeholders; process rm("rm"); rm [arg("filename") % "non_existent"] > "file.out", _2 >& _1; rm(); // or: run(rm); _________________________________ Some mini-review (concerning interface design only) on the proposed variant of the library: * process::find_executable_in_path() is a redundant function. His job must be done by default (when the filename() path's suffix supplied only instead of the full/relative path), if it's supposed on the target platform when the command shell gets the prog name from the user. In rare case the user can manipulates paths through the env(ironment variables) class (or put the full path explicitly), if default behavior is not suitable. By the way, a parameter and an return value must have been the boost::filesystem::basic_path<>, not a std::string. Obviously, the library must be integrated with the Boost.Filesystem. * A "stream behavior" boost::function<> mechanism is not obvious and not straightforward; unwarrantly hard to use. * environment(-variables) and args-list are solid abstractions (with a sharp behavior), not data structures. * child process subtype is a wrong abstraction (his "child" property isn't enough for his existence). Name it process simply. I.e. delete a child subtype from an inheritance tree; In Unix environment (similar in Windows) all processes, except INIT, have a parent: each process is a child almost without exceptions. * ----code excerpt from the User Guide-- int exit_code = child.wait(); #if defined(BOOST_POSIX_API) if (WIFEXITED(exit_code)) exit_code = WEXITSTATUS(exit_code); #endif std::cout << exit_code << std::endl; ---------------------------------------- IFDEFs must be incapsulated in the wait() member function. Signal terminating/stopping status of process can be abstracted into another terms, which are clear enough for a non "signal-conformant" platforms.

6 12

Formal Review of Proposed Boost.Process library ends Sunday!
by Marshall Clow 21 Feb '11

21 Feb '11

If you haven't submitted a review (and plan to), please do not delay. Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager (me!) Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

4 3

Re: [boost] [1.46.0] Release candidates available
by Steve M. Robbins 21 Feb '11

21 Feb '11

Successfully built the release candidate on Debian linux, 64bits. gcc (Debian 4.4.5-12) 4.4.5 -Steve

1 0

[serialization] boost/serialization/path.hpp
by Johan Råde 21 Feb '11

21 Feb '11

There is no boost/serialization/path.hpp. I suggest the following: ---------------------------------------------------------------------------------------------------------------- #ifndef BOOST_SERIALIZATION_PATH_HPP #define BOOST_SERIALIZATION_PATH_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) #pragma once #endif #include <boost/config.hpp> #include <boost/filesystem/path.hpp> #include <boost/serialization/level.hpp> BOOST_CLASS_IMPLEMENTATION(boost::filesystem::path, boost::serialization::primitive_type) #ifndef BOOST_NO_STD_WSTRING BOOST_CLASS_IMPLEMENTATION(boost::filesystem::wpath, boost::serialization::primitive_type) #endif namespace boost { namespace serialization { template<class Archive, class String, class Traits> void serialize(Archive& ar, boost::filesystem::basic_path<String, Traits>& p, const unsigned int version) { String s; if(Archive::is_saving::value) s = p.string(); ar & boost::serialization::make_nvp("string", s); if(Archive::is_loading::value) p = s; } }} #endif //-------------------------------------------------------------------------------------------------------------- Comments? Any suggested improvements? --Johan Råde

5 11

Distributed Boost with CMake: proposal and volunteering
by Daniel Pfeifer 21 Feb '11

21 Feb '11

Hi all, I would like to propose my approach to a modularized build of the Boost C++ Libraries with CMake. The project is found on http://github.com/purpleKarrot/Boost.CMake The following features are currently implemented: * Aggregate modules from different sources (CVS, SVN, GIT, tarballs, ...). * Build, Test, Install * Create a binary installer with selectable components for Windows. * Create a source package (with the modules included) that can do everything in this list (except the first entry). * Create a Debian source package that can be uploaded to a Launchpad PPA where it is built and packaged into many binary Debian packages. * Build Documentation (the usual quickbook-doxygen-boostbook-chain). * Tested on Windows (Visual Studio 10) and Ubuntu (GCC). * Precompiled headers (currently MSVC only). * Build two Boost.MPI libraries on Debian: boost_openmpi and boost_mpich2. * Tests actually make use of Boost's autolinking feature. This tool would allow the following Boost development process: * Each Boost library uses it's own repository (no matter which VCS) * Boost.CMake has a list of modules (or multiple list: eg 'boost' and 'incubating') * A modules definition consists of the information about where to get the source code from. * Boost.CMake can be used to aggregate all modules, run tests, build release packages... * Incubating libraries can be tested before they become an official part of boost. Please note that I am not proposing a development process. I am just proposing a tool. I am volunteering to extend and maintain the tool so that it can (help to) drive the development process. If you decide that all libraries should use git, I can drop the support for all other VCSs, no problem. Also, I am happy to implement other missing features. In the next couple of days I was going to write some documentation and a tutorial how to migrate the libraries to CMake. Cheers, Daniel

7 13

[gsoc] Project proposals
by Andrew Sutton 21 Feb '11

21 Feb '11

Hi all, Just a reminder the Google Summer of Code will be starting soon. Sort of. The org's application is due some time next week. If anybody has project ideas and would be willing to mentor, please add them to the wiki page, here: https://svn.boost.org/trac/boost/wiki/SoC2011 If you are adding project ideas, please remember that terse, intentionally vague descriptions will (hopefully) cause prospective students to do a little more investigation before submitting a proposal. Also, experimental projects are encouraged. The work doesn't have to be part of the Boost distribution. Long-term (multi-summer) projects may also be possible, depending on commitments from students and mentors. Please note that achieving group consensus on the requirements or design of any particular project is distinctly *not* encouraged. Trying to hash out details of a students project on the mailing list can scare away students and discourage mentors. It we be great if we can avoid a replay of the XML fiasco from last year. Finally, there was some early consensus about requiring an aptitude test in addition to the proposal. Are there any ideas on what form this should take? I think that the minimal requirement is that the user check Boost or some part of the sandbox out of SVN and build some kind of hello world program. It would be great if that program required some demonstration of familiarity with or ability to use the standard library. Any thoughts? Andrew Sutton

1 0

Re: [boost] [filesystem] temp_dir_path()
by Domagoj Saric 21 Feb '11

21 Feb '11

"Beman Dawes" <bdawes(a)acm.org> wrote in message news:AANLkTinFigAxpqkbgwQCnOXrr-Jg44=_dep1QWn+hy-Z@mail.gmail.com... > On Tue, Oct 19, 2010 at 3:35 AM, Domagoj Saric <dsaritz(a)gmail.com> wrote: >> Would it be perhaps possible to provide a lower-level function (even in >> the detail namespace) that uses a plain char buffer and an error code, >> that is free of std::vectors, std::strings, boost::paths, >> system::error_codes and >> other things one might not want to pay for (especially if one does not >> use them otherwise) just to make a system API call..? The 'proper' >> version can then wrap the thinner one... > > It would be technically possible, of course, but ... > > What you are really asking for, I think, is a C language interface or > something pretty close to that. The attitude/assumption that anything C++ must implicitly become intimate with the keywords new, virtual and throw otherwise it is actually 'only C' is just plain wrong in the fullest sense of the word: - it is wrong 'factually' not only because (most of) C is a subset of C++ but because it is quite possible to do heavy C++ programming (e.g. so heavy that it causes GCC 4.2.1 to allocate tens of gigabytes of RAM before it eventually kills the entire OS) practically without using any of the before mentioned STL 'goodies'... - it is wrong 'morally' because it is guilty of the typical 'premature pessimization' that feeds the typical anti C++ and anti Boost arguments...IOW Linus will no longer have to ask 'How many memory allocations does it take a C++ programmer to concatenate two strings?' but 'Guess how many tens of kilobytes will calling boost::temp_dir_path() add to your binary?' The 'plain char buffer' can also be understood in a more 'relaxed'/'broader' way to for example also encompass a, more C++ like, iterator_range that specifies a preallocated chunk of storage... > I could have designed the library that way, but didn't want to add a > third way for users to do things, and didn't want to take on the > increased documentation, test, etc, workload. Calling it a 'third way' is bit too hard IMO, why not think of it just as an overload (albeit of a more extreme kind)? -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

3 2

Re: [boost] [1.46.0] Release candidates available
by ktc＠ktchan.info 21 Feb '11

21 Feb '11

Philipp Reh wrote: > > I reported this problem on January 30th to the boost-devel list, > right after the beta came out, but nobody cared. Hey, I reported it before the release branch code freeze and nobody cared. *shrug* KTC -------------------------------------------------------------------- myhosting.com - Premium Microsoft® Windows® and Linux web and application hosting - http://link.myhosting.com/myhosting

3 2