- Boost - lists.preview.boost.org

[1.35.0] Host for release snapshots?
by Beman Dawes 01 Feb '08

01 Feb '08

If we are going to generate release snapshots nightly, we need a site to host them. Is Sourceforge a possibility? I seem to recall the Sourceforge release mechanism isn't particularly friendly to nightly snapshots. Ideas? --Beman

2 2

[1.35.0] Building the release?
by Beman Dawes 01 Feb '08

01 Feb '08

I'm starting to test build release candidate files for 1.35.0. The 1.34.0 and 1.34.1 release candidates were build by hand, IIUC. There is a Python script to do that job (boost-root/tools/release/make_tarballs.py), but it is out of date. I'm starting to work on updating it. What does such a script have to do? * Export SVN branches/release with the correct line endings for POSIX and Windows. * Build the quickbook/boostbook docs. * Set various file permissions. * Build the actual .zip, .gz, .bz2, and .7z files. What else? Where do the beta.boost.org web pages come from? --Beman PS: In the future, I think we should start building release files nightly for the next release as soon as a release ships. That will speed the process of identifying problems.

6 12

[review] Review of Flyweight library begins today January 7
by Ion Gaztañaga 01 Feb '08

01 Feb '08

The formal review of Flyweight library, proposed by Joaquín M. López Muñoz, begins today (sorry for the late announcement): *Description:* Flyweights are small-sized handle classes granting constant access to shared common data, thus allowing for the management of large amounts of entities within reasonable memory limits. Boost.Flyweight makes it easy to use this common programming idiom by providing the class template flyweight<T>, which acts as a drop-in replacement for const T. *Online docs:* http://tinyurl.com/2sstyr http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html *Download:* http://tinyurl.com/hrdm6 http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… *Notes:* 1) We've seen some suggestions in the mailing list for Flyweight. Joaquín has nicely explained a couple of issues that we'd like to address/discuss in the review: http://tinyurl.com/33ghtf http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/review_… 2) Flyweight needs Boost 1.35 elements because the library depends on libraries like Interprocess for some features/tests. Since SVN snapshot tarballs seem to be missing these days, those who want to try flyweight can download a working SVN-HEAD snapshot here: http://igaztanaga.drivehq.com/boost_trunk.tar.bz2 3) Serialization tests won't work. This feature is expected to work when some new features (discussed in the mailing list between Joaquín and Robert Ramey) are added in Boost.Serialization. Those are expected for Boost 1.36. What to include in Review Comments ================================== Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. 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. Ion Gaztañaga - Review Manager -

9 18

constrained_value + fixed-pt
by Neal Becker 01 Feb '08

01 Feb '08

I've been looking at constrained_value. It looks great to me, I'd love to see this added to boost. I wonder if any thought has been given (or work done) in using this to implement fixed point arithmetic?

1 0

[rfc] I/O Chain Library, Preview Release
by Sebastian Redl 01 Feb '08

01 Feb '08

Hi, Back in June I posted some thoughts about what I'd expect from a properly done I/O library.[1] Based on the ensuing discussion I then designed such a library. Over the last months, I've worked hard at implementing the thing. It is with quite a bit of pride, then, that I announce the IOChain preview release 1. You can get the source here: http://stud3.tuwien.ac.at/~e0226430/iochain-preview-1.tar.bz2 There are currently some assumptions in the build files that require a tiny bit of setup. 1) Unpack the source into some directory. 2) Grab the latest Boost trunk. 3) In the unpacked source, make a symlink to the Boost trunk called "realboost". E.g. tar -xjf iochain-preview-1.tar.bz2 cd iochain ln -s /path/to/boost/trunk realboost 4) Add zlib to your user config. If you have zlib where it is easily found, this is as easy as adding this line to ${HOME}/user-config.jam: lib zlib : : <name>z ; I'm sorry for the inconvenience. Documentation is in quickbook format. A generated version is available here: http://stud3.tuwien.ac.at/~e0226430/iochain/ This is a preview release. Its only purpose is to get comments. It has not seen widespread compiler testing yet (only GCC 4.1 on a 64-bit Linux). Features implemented so far: - The infrastructure. - File I/O (POSIX only - a Win32 implementation exists, but hasn't seen a compiler yet, so don't expect it to compile, much less work) - In-memory I/O (fixed buffers and std::vector). - Read-ahead and write-collect buffers (like buffering in the current streams). - Various tools to support backtracking. - Combining bytes into larger types. (Only naive methods currently.) - On-the-fly CRC calculation. - On-the-fly zlib compression. The ultimate goal of the library is to completely replace iostreams. All discussion, suggestions, and criticisms are welcome. Sebastian Redl [1] http://lists.boost.org/Archives/boost/2007/06/123478.php

5 11

[Pool] CRITICAL _SECTION ambiguous symbol
by Samuel Debionne 01 Feb '08

01 Feb '08

Hello all, I have the following compile error in my project, using the SVN release branch : boost\boost\boost/pool/detail/mutex.hpp(67) : error C2872: 'CRITICAL _SECTION' : ambiguous symbol could be 'C:\Program Files\Microsoft Platform SDK\include\winbase.h(295) : RTL_CRITICAL_SECTION CRITICAL_SECTION' or 'third_party\boost\boost\boost/detail/lwm_win32_cs.hpp(33) : boost::d etail::CRITICAL_SECTION' It can be easly by fixed by adding "::" in front of the CRITICAL_SECTION member definition of the win32_mutex class (see pool/detail/mutex.hpp). But is there any reason not to use boost/detail/lightweight_mutex.hpp in the pool library ? Regards, Samuel

1 0

[property_tree] - segmentation fault
by Kowalke Oliver (QD IT PA AS) 01 Feb '08

01 Feb '08

Hello, I get an segmentation fault from the property_tree (1_35 trunck): Program terminated with signal 11, Segmentation fault. #0 0xb7cba2ba in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0xb7cba2ba in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6 #1 0x080d4107 in pair (this=0xa44f1284, __a=@0x891acbc, __b=@0x891acc0) at /usr/include/c++/4.2/bits/stl_pair.h:85 #2 0x080d0510 in boost::property_tree::basic_ptree<std::less<std::string>, std::string, boost::property_tree::basic_path<std::string>, std::string, boost::property_tree::translator>::insert<std::_List_const_iterator<std::pair<std::string, boost::property_tree::basic_ptree<std::less<std::string>, std::string, boost::property_tree::basic_path<std::string>, std::string, boost::property_tree::translator> > > > ( this=0xa44f1318, where={_M_node = 0xa44f131c}, first={_M_node = 0x891acb4}, last={_M_node = 0x891bf80}) at /opt/boost/include/boost-1_35/boost/property_tree/detail/ptree_implementation.hpp:304 #3 0x080d0648 in basic_ptree (this=0xa44f1318, rhs=@0x891bf7c) at /opt/boost/include/boost-1_35/boost/property_tree/detail/ptree_implementation.hpp:65 Any ideas what happened - until now property_tree worked without probs!? best regards, Oliver

1 0

<kein Betreff>
by Hansi Hansi 01 Feb '08

01 Feb '08

>> >> I took Matthias' suggestion above to mean he thought the density >> accumulator could be given additional "min" and "max" constructor >> parameters, not that we need a whole new accumulator. Matthias, was >> that >> what you were suggesting? I'd rather go that route. >Yes, that was my suggestion. Or we could implement the current one >based on the simpler one. >Matthias Okay. Maybe I have missunderstood something. Should the implementation be in the class density and optional min/max parameters? Best regards Hansjörg _____________________________________________________________________ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071&distributionid=000000000066

1 0

BoostCon 2008 Now Open For Registration
by David Abrahams 01 Feb '08

01 Feb '08

Hi All, The 2nd annual Boost Conference has been scheduled for May 4-9 2008. Please see http://www.boostcon.com/registration for registration information. If you want to stay at the Aspen Meadows (highly recommended as it is within walking distance of the conference venue and was the site of great after-hours discussions in '07), it's especially important this year that you book your rooms early. Since, unlike last year, Aspen's airport will be open this May, demand for rooms has been heavy. In fact, the following week, which we tried to get, was snapped up by another group before we even had a chance to catch our breath, just weeks after BoostCon'07 ended. We'll be working hard on getting the program together for 2008 over the coming weeks. We hope to include many more Boost authors and contributors, and build in several more intensive library-specific sessions, to make 2008 better than ever. Please send any questions to the BoostCon planning committee at: organizers(a)boostcon.com. Those of you who didn't make it to BoostCon'07 may want to have a look at the photo gallery at http://boostcon.com/community/photos, peruse the 2007 program at http://boostcon.com/program, and check out the two trip reports mentioned here: http://boostcon.com/news/2007/Jul/16/yet-another-trip-report. See you in Aspen! -- The BoostCon Planning Committee

4 4

Reporting bugs at Trac?
by Olaf van der Spek 01 Feb '08

01 Feb '08

Hi, http://boost.org/more/bugs.htm > Submit a bug report to either boost-users list, boost mailing list, or our bug tracking facility; IIRC Trac accounts are only for developers. Maybe it's a good idea to include a Register link anyway and explain this? > submitting it to either of the mailing lists is a preferred way - because many of the Boost developers read the lists on a daily basis, this way you are likely to get a quicker response, and the discussions that often arise there from (possible) bug reports are quite interesting and educational as well; Why aren't reports from Trac forwarded to the mailing lists then? Greetings, Olaf

2 5

Combine enable_if and concept check
by Johan Torp 01 Feb '08

01 Feb '08

Is there any way to combine boost::enable_if and the concept check library? For instance to disable a function overload for template parameters which doesn't model some STL concept. Best Regards, Johan Torp -- View this message in context: http://www.nabble.com/Combine-enable_if-and-concept-check-tp15181277p151812… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

Boostcon 2008- should I book my flights?
by Terence Wilson 01 Feb '08

01 Feb '08

Hello all, Can anyone give me a status update, is registration open yet? Thanks, Terence

3 4

[trac][wiki] Correct wiki for development
by Jonathan Turkanis 01 Feb '08

01 Feb '08

Hi, I'd like to prepare some notes about future development of Boost.Iostreams and make them available in a shared location. I'm wondering if I should use the trac wiki or the user wiki at crystalclearsoftware.com. I'm inclined to say it should be the trac wiki, but I don't see anything similar there, except for "Boost.Graph Version 2", under "Projects" on the home page. Can I just create a Boost.Iostreams link under "Projects"? Thanks, -- Jonathan Turkanis CodeRage http://www.coderage.com

2 1

[1.35] proposal to add two platforms as release platforms for 1.35
by Boris Gubenko 01 Feb '08

01 Feb '08

I'd like to propose two additional platforms as release platforms for 1.35: 1. gcc-3.4.6_linux_ia64 (runner id: linux_ia64_gcc). It is all green on the trunk with Interprocess library marked as n/a. 2. gcc-4.2.1_hpux_ia64 (runner id: HP-UX_ia64_gcc). Three libraries are currently failing on trunk: Interprocess, Regex and Serialization. . Interprocess library: as for other HP platforms, this library will have to be marked n/a. I don't believe I'll have time to investigate failures and propose fixes in the 1.35 timeframe. . Regex library: fails because of the problem in <http://lists.boost.org/Archives/boost/2008/01/132318.php> The problem does not exist in release branch (and is fixed in trunk by <http://svn.boost.org/trac/boost/changeset/42745>) . Serialization library: test_exported* group of tests fail the same way they fail on all the platforms with gcc 4.1 and higher, including BGD-Ubuntu, which is a release platform for 1.35. I assume, this issue will be resolved before 1.35 is released and resolution will automatically cover gcc-4.2.1_hpux_ia64 as well. If I get a permission, I'll start testing these platform on the release branch, in addition to continuing testing on trunk. Thanks, Boris

3 3

Errors in status/explicit-failures-markup.xml?
by Jens Seidel 01 Feb '08

01 Feb '08

Hi, I noticed that status/explicit-failures-markup.xml seems to contain some errors. I really wonder e.g. about "These compilers are unfortunately able to correctly compile". It looks like there is a "not" missing in this sentence (multiple times!). Jens

4 4

Document python::handle behavior
by Neal Becker 01 Feb '08

01 Feb '08

To allow handle to work with various PyObject compatible types, handle relies on specializations of base_type_traits. I don't think that's mentioned in the reference docs, and leads to mysterious compile errors to the un-initiated.

2 1

Boost serialization DLL issues on x64 platforms
by Terence Wilson 01 Feb '08

01 Feb '08

Folks, I've finally found the cause of a problem that has been tripping us up for some time. We have a Windows application that we build for IA32 and x64. Naturally the IA32 version links against 32-bit import libraries and the x64 64-bit import libraries. But here's the rub: Boost generates output binaries with the same name for both platforms: bjam -sTOOLS=vc-8_0 bjam -sTOOLS=vc-8_0-amd64 both result in boost_serialization-vc80-mt-gd-1_33_1.lib boost_serialization-vc80-mt-gd-1_33_1.dll being created (among other things). Now because the Windows loader simply searches the PATH for the first DLL that matches the name of the import library, an x64 application linked against the x64 import library for Boost Serialization might load the IA32 version at runtime. Most other tool vendors solve this one by attaching a 'x64' suffix to the import and DLL filenames. However, despite what the Boost Build documentation says, the tool name "vc-8_0-amd64" is not used when building the DLL file name. We get stuck with the same filename for both platforms. Simply rename the files? Nope, the binary import library contains decorated names prefixed with the DLL name. The best fix would be to make bjam do the right thing: boost_serialization-vc80-amd64-mt-gd-1_33_1.lib boost_serialization-vc80-amd64-mt-gd-1_33_1.dll Am I missing something here? Thanks in advance, Terence

1 0

Re: [boost] Boost pool allocator slower than STL allocator
by Robin 01 Feb '08

01 Feb '08

Hi I've been testing out boost pool allocator, and my results shows it's slower than the STL allocator. I'm using VSNet 2005 SP1. See test code below. Also, on a separate issue, I notice the pool_allocator uses a singleton with static member in a function (Meyer's singleton). While this avoid the static construction issue, it does not free the memory until the application quits. This would work fine only POD data, if the dtor depends on a system in the application, it won't work. Shouldn't there be a pool allocator which can be used like the object_pool? Robin Test code -------- With boost pool, timing on average is (0.03) vs STL (0.02) seconds in release mode. In debug mode, its boost (0.99) vs STL (0.8) #include <boost/pool/pool_alloc.hpp> #include <iostream> #include <vector> using namespace std; class A { int x, y; public: A () : x (0), y (0) {} }; #include <windows.h> class Timer { public: Timer() { reset(); } /// reset() makes the timer start over counting from 0.0 seconds. void reset() { unsigned __int64 pf; QueryPerformanceFrequency( (LARGE_INTEGER *)&pf ); freq_ = 1.0 / (double)pf; QueryPerformanceCounter( (LARGE_INTEGER *)&baseTime_ ); } /// seconds() returns the number of seconds (to very high resolution) /// elapsed since the timer was last created or reset(). double seconds() { unsigned __int64 val; QueryPerformanceCounter( (LARGE_INTEGER *)&val ); return (val - baseTime_) * freq_; } /// seconds() returns the number of milliseconds (to very high resolution) /// elapsed since the timer was last created or reset(). double milliseconds() { return seconds() * 1000.0; } private: double freq_; unsigned __int64 baseTime_; }; int main () { Timer timer; for (int i = 0; i < 10; ++i) { // Switch allocators // typedef vector <A> VectorA; typedef vector <A, boost::pool_allocator <A> > VectorA; VectorA vectorA; double startTime = timer.seconds (); for (int jj = 0; jj < 1000000; ++jj) { vectorA.push_back (A()); } double endTime = timer.seconds (); cout << "Time taken is " << i << " - " << endTime - startTime << endl; } return 0; } > On 30/12/2007, Robin <al(a)cyberversion.com> wrote: > >> _______________________________________________ >> Unsubscribe & other changes: >> http://lists.boost.org/mailman/listinfo.cgi/boost >> > > It seems your message got sent without any body text.

4 4

BoostBook/QuickBook
by brook＠biology.nmsu.edu 01 Feb '08

01 Feb '08

I am ready to markup the documentation for a library, but am lost with respect to getting started with the documentation tools BoostBook and QuickBook. I think I can understand the markup itself, but as far as I can tell there is no documentation on actually building and using the tools, the files produced, etc. Any guidelines would be very appreciated. Cheers, Brook

3 2

Re: [boost] [review] Review of Flyweight library started January 21 and still running!: Alternative/simpler configuration interface
by "JOAQUIN LOPEZ MU?Z" 31 Jan '08

31 Jan '08

"vicente.botet" ha escrito: > Maybe this should be managed orthogonally but, can the current design > managewith persistent flyweights? > Which policies will we reused and which ones added? Hi, Here is a basic example of how to make a persistent factory (not to be confounded with serializaing flyweight objects, which is an entirely different matter). The factory below is based on a std::set and loads and saves its contents upon construction/destruction: template<typename Entry,typename Value,const char* Filename> class serialized_set_factory_class: public boost::flyweights::factory_marker { typedef std::set<Entry,std::less<Value> > container_type; public: typedef typename container_type::iterator handle_type; typedef typename container_type::value_type entry_type; serialized_set_factory_class() { std::ifstream ifs(Filename); if(ifs){ boost::archive::text_iarchive ia(ifs); typename container_type::size_type s=0; ia>>s; for(typename container_type::size_type n=s;n--;){ Value v; ia>>v; cont.insert(cont.end(),Entry(v)); } std::clog<<"loaded "<<s<<" entries from "<<Filename<<"\n"; } } ~serialized_set_factory_class() { std::ofstream ofs(Filename); boost::archive::text_oarchive oa(ofs); typename container_type::size_type s=cont.size(); oa<<s; for(typename container_type::iterator it=cont.begin (),it_end=cont.end(); it!=it_end;++it){ oa<<static_cast<const Value&>(*it); } std::clog<<"saved "<<s<<" entries to "<<Filename<<"\n"; } handle_type insert(const entry_type& x) { return cont.insert(x).first; } void erase(handle_type h) { cont.erase(h); } const entry_type& entry(handle_type h){return *h;} private: container_type cont; }; template<const char* Filename> struct serialized_set_factory:boost::flyweights::factory_marker { template<typename Entry,typename Value> struct apply { typedef serialized_set_factory_class< Entry,Value,Filename > type; }; }; We can use it just like this: extern const char filename[]="fw.bd"; typedef flyweight< std::string, serialized_set_factory<filename>, no_tracking > fw_t; Note that we're using no_tracking: if the normal refcounted tracking were used, there would be no elements remaining in the factory by the time it is destroyed, and hence nothing to persist. The attached snippet exercises these ideas. It compiles and runs OK with GCC 3.4.4 under Cygwin. You need to link Boost.Serialization. Hope this addresses your concerns about the potential of the lib to accomodate persistent factories. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[build][wave] tools/wave link failure
by Stefan Seefeld 31 Jan '08

31 Jan '08

I have talked to multiple developers about this, yet none has assumed responsibility, so I'm not sure where to raise this: Building inside boost/tool/wave/build on trunk fails for me due to a link error, since wave wants to link to boost_thread, but doesn't link to -lpthread. (This is the default toolchain on my Fedora 8 box, i.e. GCC.) I'm not sure where the -lpthread needs to be added (I added it manually to the link command and it succeeded), or in fact, why wave links to boost_thread at all. It doesn't use threads underneath, or does it ? Another point I just touched on with Volodya on IRC is that all tools are built against the static boost libraries, presumably because Windows doesn't have the equivalent of -rpath. Could that be changed at least for non-Windows platforms that would allow it ? Thanks, Stefan PS: Thanks for changing the default to only build a single variant. It's *much* more pleasant to work with trunk now ! -- ...ich hab' noch einen Koffer in Berlin...

3 6

accumulators::histogram
by Neal Becker 31 Jan '08

31 Jan '08

I see accumulators::density is almost what I want. I need a histogram, but it want to specify in advance the number of bins and the bin size. This is really a simplified accumulators::density. I think it would be good to add this to accumulators::density.

4 8

Re: [boost] preview of a template geometry library
by Tom Brinkman 31 Jan '08

31 Jan '08

I'm a long-time follower of this mailing list, and a former "Review Wizard". I think that this geometry is more than adquate for a full review by the boost members. It may not meet everyones needs, but a detailed review of a geometry library would be most welcome and needed. Even if its not approved initially, it will set the standard of what we want in geometry library. I have a feeling that we have many experts in this area, many of which could give detailed reviews. Any geometry library author willing to throw his hat in the ring so-to-speak should be welcomed and encouraged. I've reviewed the documentation (1 hour), and the authors appear to be strong domain experts and have more than a fair chance of getting it approved. I thank that a boostified geometry is badly needed. I would also like to help ensure that it is compatible with boost::gil. The two would compliment each other. Thanks for submitting this library and offering it up for review.

2 1

[FileSystem] Link errors on OS X 10.4.11 with Intel C++ Vers 10.1
by Mike Jackson 31 Jan '08

31 Jan '08

While trying to create an intermediate dynamic library on OS X 10.4.11 (Intel) that utilizes boost::file_system I receive the following link errors: Linking CXX shared library Bin/libMXADataModel.dylib xilibtool: executing 'libtool' ld: common symbols not allowed with MH_DYLIB output format with the - multi_module option CMakeFiles/MXADataModel.dir/src/HDF5/H5MXADataFile.o definition of common __ZZN5boost10filesystem12initial_pathINS0_10basic_pathISbIwSt11char_trai tsIwESaIwEENS0_12wpath_traitsEEEEERKT_vE9init_path (size 16) CMakeFiles/MXADataModel.dir/src/HDF5/H5MXADataFile.o definition of common __ZZN5boost10filesystem12initial_pathINS0_10basic_pathISsNS0_11path_trai tsEEEEERKT_vE9init_path (size 16) CMakeFiles/MXADataModel.dir/src/HDF5/H5MXADataFile.o definition of common __ZZN5boost10filesystem6detail14remove_all_auxINS0_10basic_pathISbIwSt11 char_traitsIwESaIwEENS0_12wpath_traitsEEEEEmRKT_E7end_itr (size 16) CMakeFiles/MXADataModel.dir/src/HDF5/H5MXADataFile.o definition of common __ZZN5boost10filesystem6detail14remove_all_auxINS0_10basic_pathISsNS0_11 path_traitsEEEEEmRKT_E7end_itr (size 16) libtool: internal link edit command failed make[2]: *** [Bin/libMXADataModel.dylib] Error 1 make[1]: *** [CMakeFiles/MXADataModel.dir/all] Error 2 make: *** [all] Error 2 This is reproducible on the system by simply including boost/ filesystem/operations.hpp in any file that is built into the library. Thanks for your attention to this bug. I have also submitted this as bug #1613. ------------- Mike Jackson Senior Software Engineer IMTS.us

1 0

Re: [boost] accumulators::histogram
by Hansi Hansi 31 Jan '08

31 Jan '08

I have made the changes for the "easy" histogram implemenation. Best regards Hansjörg _____________________________________________________________________ Unbegrenzter Speicherplatz für Ihr E-Mail Postfach? Jetzt aktivieren! http://www.digitaledienste.web.de/freemail/club/lp/?lp=7

1 0