September 2008 - Boost - lists.boost.org

Re: [boost] Boost 1.36.0 release notes missing Circular Buffer changes
by Jan Gaspar 02 Sep '08

02 Sep '08

Yes, that's true. Not sure it is possible at this stage when Boost 1.36 has been released but all will be OK in the next version. Jan ----- Original Message ---- From: Dean Michael Berris <mikhailberis(a)gmail.com> To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> Sent: Monday, 1 September, 2008 9:25:49 Subject: [boost] Boost 1.36.0 release notes missing Circular Buffer changes Hi, I took a look at the code in trunk and in 1.36.0, and I notice the release notes don't mention the change in behavior of Boost.Circular_Buffer WRT the default constructor. Should we add: Circular Buffer: * default constructor now doesn't allocate memory, and sets the capacity of the buffer to 0 To the 1.36 release notes? -- Dean Michael C. Berris Software Engineer, Friendster, Inc. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

5 6

Error compiling date_time with Sun Studio 11 on Solaris 8
by ow 02 Sep '08

02 Sep '08

Am getting the following error(s) when trying to include "boost/date_time/local_time/local_time.hpp" on the sun platform. Same code compiles ok on linux and windows. Error, nomatchoverin: Could not find a match for std::has_facet<std::Facet>(std::locale) needed in boost::gregorian::operator<<<char, std::char_traits<char>>(std::ostream &, const boost::gregorian::date&). Can anyone help ? -- View this message in context: http://www.nabble.com/Error-compiling-date_time-with-Sun-Studio-11-on-Solar… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[thread] wrong assertion following call to pthread_mutex_timedlock()?
by Wolfgang Fertsak 02 Sep '08

02 Sep '08

In boost 1.35 and 1.36 the implementation of mutex::timed_lock() and recursive_mutex::timed_lock() for posix-platforms with BOOST_PTHREAD_HAS_TIMEDLOCK defined looks like this: bool timed_lock(system_time const & abs_time) { struct timespec const timeout=detail::get_timespec(abs_time); int const res=pthread_mutex_timedlock(&m,&timeout); BOOST_ASSERT(!res || res==EBUSY); return !res; } The assertion following pthread_mutex_timedlock() always fails in case of a timeout since the system call returns ETIMEDOUT when timed out and not EBUSY (according to the open group specification http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_timed…) Best regards, Wolfgang

2 1

Re: [boost] Try-out Adler-32 code?
by Bram Neijt 02 Sep '08

02 Sep '08

Hi Daryle, I tried publishing an MD5 algorithm inside one of my programs as a debian package, but there where problems with the licensing. Please take care that the implementation is fully licensed and you mention the right parties everywhere. I'm not sure how you should go about this, but these are just my 2 cents ;) Bram On Mon, 2008-09-01 at 16:03 -0400, Daryle Walker wrote: > I added Adler-32 code to the MD5 trial library at <http:// > svn.boost.org/trac/boost/browser/sandbox/md5>, if anyone would like > to try it out and comment. >

3 2

Re: [boost] [flyweight] post-review version available
by Johannes Brunen 02 Sep '08

02 Sep '08

Hello, Joaqu?n M L?pez Mu?oz wrote: > I forgot to mention that this version has to be built against the > trunk version of Boost (it uses boost::swap, which hasn't made it > to any Boost release yet). Would it possible to provide a version compatible with the current 1.36.0 release. Until version 1.38.0 is quite some time and I would be interested in playing with the library. However, I'm only working with the release package of the boost libraries. Best, Johannes ____________ Virus checked by G DATA AntiVirusKit Version: AVK 19.274 from 02.09.2008 Virus news: www.antiviruslab.com

2 1

Should we provide hot fixes?
by Beman Dawes 02 Sep '08

02 Sep '08

Although it does look like we will be able to hold to a quarterly release schedule, it is really doubtful we have enough resources to issue point releases. To get bug fixes into user's hands more quickly, should we provide hot fixes when appropriate? Hot fixes might work something like this. (I'll use an embarrassing Boost.Filesystem mistake I made as an example.) * Individual developers will decide on a case-by-case basis if they want to provide a hot fix for a given bug. * There would be a prominent link on the web site to a "Hot Fixes" page in the trac. * That "Hot Fixes" page would have a section for each release. * Under release 1.36.0, there would be a changeset number, a description of the problem, and a directory-location: 48192 Restore deprecated basic_directory_entry names inadvertently removed. (boost/filesystem) * The changeset number would link to http://svn.boost.org/trac/boost/changeset/48192 * The "Hot Fixes" page would include instructions on how to apply a changeset. The instructions are the same for all operating systems: -- Click on "Download in other formats: Unified Diff". -- From the command prompt, cd directory-location patch <download-location/changeset_r48192.diff * The "Hot Fixes" page would include instructions on how to install "patch" for popular operating systems, and give an example of actual usage. Comments? --Beman

23 81

Try-out Adler-32 code?
by Daryle Walker 01 Sep '08

01 Sep '08

I added Adler-32 code to the MD5 trial library at <http:// svn.boost.org/trac/boost/browser/sandbox/md5>, if anyone would like to try it out and comment. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[interprocess][process] Synchronizing libraries and efforts (+ bugs)
by Ion Gaztañaga 01 Sep '08

01 Sep '08

Hi to all, I recently needed s library to launch processes and I took a look to the recently announced Process 0.2 (http://lists.boost.org/Archives/boost/2008/07/139322.php) I just needed the library for Windows, and I think the library is interesting although still lacking in some basic aspects (explained later in this post). A process-launching library is a very nice utility for Interprocess and I was thinking of adding this possibility for a future version (Boost 1.37 or 1.38) of the library. If Boost.Process is going forward, it would be glad to collaborate and develop a library that can satisfy all our needs and plays nicely with Interprocess. My main requests for a process-launching library are: 1) Ability to launch a process and a blocking or non-blocking wait operation to obtain its result (Boost.Process already has this). 2) Ability to redirect child process stdin/stdout/stderr to /dev/null, to share the stdin/stdout of the parent or to redirect it to a file. And in the latter case, append or overwrite options (Boost.Process implements some of this options). I slightly modified Boost.Process to implement a rought version of file redirection. 3) Ability to modify the environment variables of the child (Boost.Process already has this). 4) Blocking and non-blocking redirections of stdout and helper functions to simplify its usage (Boost.Process does not have this). For example: bool send_stdio_and_get_stdout (const void* stdin, std::size_t stdin_size, std::vector<char> &stdout); or similar would avoid many programming errors because at any moment stdin can block and we must extract stdout so that the child process can continue processing stdin. 5) I don't know if streams are the right way to communicate with processes, because they don't offer non-blocking support. 6) I think that process-launching interface should be similar to the soon to be standardized C++ futures. So I'm interested in a process-launching library and I offer my collaboration in case Boost.Process development needs help. Regards, Ion PS: Some possible bugs found on Boost.Process 0.2 version (Windows): -> main thread handle returned by CreateProcess in PROCESS_INFORMATION structure the must be closed and I can't find this in the code. -> child::wait function returns sporadic errors when multiple children are launched and waited. I changed the code from: do { ::GetExitCodeProcess(handle_, &code); ::Sleep(500); } while (code == STILL_ACTIVE); ::WaitForSingleObject(handle_, 0); ::CloseHandle(handle_); with ::WaitForSingleObject(handle_, INFINITE); ::GetExitCodeProcess(handle_, &code); ::CloseHandle(handle_); ->environment::set does not correctly overwrite existing variables): void set(const std::string &var, const std::string &value) { insert(value_type(var, value); } should be void set(const std::string &var, const std::string &value) { this->operator[](var) = value; } -> Using named pipes has been problematic because it returns errors when launching multiple processes aggressively: Error 231 - All Pipes are Busy. This does not happen with anonymous pipes and I think it has some relationship with the guid code. By the way, I think a uuid library is too much to create a unique identifier to be shared with the child a simple atomic count would to the job in my opinion. That would reduce Boost.Process dependencies. -> systembuf::close() should call sync() to push the last charaters into the pipe, othewise, characters are lost if the user does not flush the stream. -> I've changed the "stream_info::usefile" case in win32_start to support redirecting to files, changing "CREATE_NEW" parameter of CreateFileA with CREATE_ALWAYS. -> And now, the most important one ;-) Please, avoid tabs! Read boost development guidelines: http://www.boost.org/development/requirements.html#Tabs

3 10

[serialization][frame] Is there any interest in a frame serialization library?
by vicente.botet 01 Sep '08

01 Sep '08

Hi, >From wikipedia "a frame is a data packet of fixed or variable length which has been encoded by a data link layer communications protocol for digital transmission over a node-to-node link. Each frame consists of a header frame synchronization and perhaps bit synchronization, payload (useful information, or a packet at higher protocol layer) and trailer. Examples are Ethernet frames and Point-to-point protocol (PPP) frames." Is there any interest in a frame library which will be based on an extension of the archive concept. The saving archive concept allows to save serializable data at the end of the archive, and the loading archive concept allows to read serializable data from the begining of the archive. The saving frame concept will allows to save serializable data either at the end or the *begin* of the frame, and the loading frame concept allows to read serializable data from the begining or the *end* of the archive. I'm not sure which syntax will be the more adequated. The serialization library use the <<, >>, and & operators that are associative from left to right. We need the equivalent operators from right to left. <<=, >>=, and &= seams to be the more adequated candidates but I don't know if it is correct in C++ to define this operators with this prototype template <typename T> frame& operator<<=(const T&, frame&); template <typename T> frame& operator>>=(const T&, frame&); template <typename T> frame& operator&=(const T&, frame&); h1 >>= h2 >>= sf << t2 << t1 ~ (h1 >>= (h2 >>= ((sf << t2) << t1))) sould be equivalent to sa & h1 & h2 & t2 & t1 if sf and sa were empty. The main difference is that we can do it hierarchically. The top layer will create a frame, and serialize its own information elements. frame sf; h_n >>= sf << p_n << t_n; Then this top layer will use a primitive of the lower level having as parameter the frame as payload. primitive_n-1(sf); A primitive at the k level will add its own header and trailer information element to the payload of the upper level void primitive_k(frame& sf) { // ... h_k >>= sf << t_k; // ... another_primitive_k_1(sf); // ... } So the frame allows to serialize top-down. With the archive concept the serialization must be done bottom-up, needing to chain each one of the information element in a list and only when we have all off them we can start the serialization. I think that the frame approach should be more efficient because it avoid to store in dynamic memory the information elements to be serialized, instead they are serialized directly. Loading a frame works as loading an archive, except that we can load also at the end of the frame. This avoids to load the complete archive to load the trailer of the lower levels. lf >>= h_1; // ... t_1 << lf; In addition, it would be greate to have saving/loading frames (I'm not sure but I think that an archive can not be saving and loading at the same time). The same frame can be used as loading, analyzing only some lower levels, and as saving in order to construct other lower levels. This will be very useful for gateways and routers. | L4 |<----------------------------->| L4 | | L3 | | ADAPTATION | | L3 | | L2 |<-->| L2 | | X2 | <--> | X2 | | L1 |<-->| L1 | | X1 | <--> | X1 | It would be greate that the same data that can be serialized on archives, could be serializable on a frame using the same save function. But this works only when we save at the end of the frame. Let me see this using a little example: Class C has 3 information elements to serialize (a, b and c). So the save functions could be something like template <typename ARCHIVE> void C::save(ARCHIVE& sa) { sa & a & b & c; } This save function works well from left to right, but can not be used when saving at the begining of a frame, because the expected result when saving at the begining is | a | b | c | sa | but the result will be | c | b | a | sa | So unhappylly we need a different save function template <typename FRAME> void C::save(FRAME& sa, begin_tag&) { a >>= b >>= c >>= sa; // a >>= (b >>= (c >>= sa)); } Please let me know if you are interested in such a library, and what are your requirements. Robert, do you think that this can be seen as an extension of the serialization library? Best regards, Vicente Juan Botet Escriba

1 0

[log] filtering performance
by Igor Nazarenko 01 Sep '08

01 Sep '08

It seems that the library does quite a bit of work before filtering away a record, unless the logging is turned off entirely. There's at least two mutex locks, some memory allocation, etc. Callgrind claims ~2500 instructions when the record is thrown away by the global severity filter. Shortened callgrind output is in-line below; full output and the test program attached. Compiled by gcc 4.2.3 using boost.build variant=release threading=multi. 7 BOOST_LOG_SEV(slg, normal) << "A normal severity message, will not pass to the output (global filter)"; 99,557 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, normal) << "A normal severity message, will not pass to the output (global filter)"; 2,530 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, normal) << "A normal severity message, will not pass to the output (global filter)"; 2,530 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, warning) << "An warning severity message, will not pass to the output (sink filter)"; 5,212 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, warning) << "An warning severity message, will not pass to the output (sink filter)"; 3,904 => bool basic_severity_logger::open_record() (1x) 7 BOOST_LOG_SEV(slg, warning) << "An warning severity message, will not pass to the output (sink filter)"; 3,904 => bool basic_severity_logger::open_record() (1x) . 10 BOOST_LOG_SEV(slg, error) << "An error severity message, will be printed"; 218,306 => record_pump::~record_pump() (1x) 24,144 => bool basic_severity_logger::open_record() (1x) 10 BOOST_LOG_SEV(slg, error) << "An error severity message, will be printed"; 28,963 => record_pump::~record_pump() (1x) 5,074 => bool basic_severity_logger::open_record() (1x) 11 BOOST_LOG_SEV(slg, error) << "An error severity message, will be printed"; 28,644 => record_pump::~record_pump() (1x) 5,074 => bool basic_severity_logger::open_record() (1x)

2 1