- Boost - lists.boost.org

[modularization] Modularizing Boost (modularization)
by Stephen Kelly 05 Nov '13

05 Nov '13

Hi there, my plan for modularizing and modernizing Boost was roughly this: * Phase 0 - remove dead weight by bumping compiler feature requirements * Phase 1 - move some files around so that the modularized repos form a mostly directed graph * Phase 2 - Form some kind of 'boost core library' or 'boost feature normalization library' from the guts of existing libraries like type_traits, static_assert, config mpl and utilities. * Phase 3 - Try to port the mpl to variadic templates so that the dependency on Boost.PP is not needed when variadic templates are available. I recommend completing up to phase 2 before migrating to git, as otherwise files will have to be deleted from one repo, and added to another without history. Phase 0 is aborted, so let's look at phase 1. [Note: This should go without saying, but my experience on this list tells me it needs to be said: * I do not propose making many commits with the commit message 'migrate' * The below is scripted for your understanding only. Scripting gives an exactness which prose does not, and allows reproducibility. Don't take it too literally. * Of course, forwarding headers should be understood to be left behind when a file is moved, where possible. * Don't cry too loudly about where I'm moving files to. See Phase 2 above, and understand that this is partly only an experiment to see how modularization can be done. EndNote] If the dependencies between repositories are analysed, the result is this graph: http://steveire.com/boost/graph_all.dot http://steveire.com/boost/graph_all_small.png There are 104 nodes and 1159 edges. Each edge is a real dependency which exists between repos, and which will exist between boost modularized packages. They should not be considered optional. If we remove any nodes which are not strongly connected, we are left with a new graph of nodes which are all strongly connected: http://steveire.com/boost/graph_strong.dot http://steveire.com/boost/graph_strong_small.png There are 68 nodes and 675 edges. Move enable_if from utility to type_traits: git submodule foreach 'git grep -l -P utility/enable_if.hpp -- include/boost | xargs sed -i "s|utility/enable_if.hpp|type_traits/enable_if.hpp|" || echo' mv libs/utility/include/boost/utility/enable_if.hpp libs/type_traits/include/boost/type_traits git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 670 edges and 68 nodes. Next, move boost/detail/workaround.hpp to the config library/repo: git submodule foreach 'git grep -l -P boost/detail/workaround.hpp -- include/boost | xargs sed -i "s|boost/detail/workaround.hpp|boost/config/workaround.hpp|" || echo' mv libs/detail/include/boost/detail/workaround.hpp libs/config/include/boost/config/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 661 edges and 68 nodes. Next, move boost/limits.hpp to the config library/repo: git submodule foreach 'git grep -l -P boost/limits.hpp -- include/boost | xargs sed -i "s|boost/limits.hpp|boost/config/limits.hpp|" || echo' mv libs/detail/include/boost/limits.hpp libs/config/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 653 edges and 68 nodes. Next, move boost/detail/iterator.hpp and boost/iterator/iterator_traits.hpp to the type_traits library/repo: git submodule foreach 'git grep -l -P boost/detail/iterator.hpp -- include/boost | xargs sed -i "s|boost/detail/iterator.hpp|boost/type_traits/detail/iterator.hpp|" || echo' git submodule foreach 'git grep -l -P boost/iterator/iterator_traits.hpp -- include/boost | xargs sed -i "s|boost/iterator/iterator_traits.hpp|boost/type_traits/iterator_traits.hpp|" || echo' mv libs/detail/include/boost/detail/iterator.hpp libs/type_traits/include/boost/type_traits/detail/ mv libs/iterator/include/boost/iterator/iterator_traits.hpp libs/type_traits/include/boost/type_traits git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 650 edges and 68 nodes. Next, move boost/iterator.hpp from iterator to the utility library/repo: mv libs/iterator/include/boost/iterator.hpp libs/utility/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 649 edges and 68 nodes. utility no longer depends on iterator. Move boost/version.hpp to config: mv libs/detail/include/boost/version.hpp libs/config/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 512 edges and 64 nodes. The config, integer, io and static_assert libraries are no longer part of the mesh Next, move boost/pointee.hpp from iterator to detail: mv ./libs/iterator/include/boost/pointee.hpp libs/detail/include/boost/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' Move exception/detail/attribute_noreturn.hpp into config: git submodule foreach 'git grep -l -P boost/exception/detail/attribute_noreturn.hpp -- include/boost | xargs sed -i "s|boost/exception/detail/attribute_noreturn.hpp|boost/config/attribute_noreturn.hpp|" || echo' mv libs/exception/include/boost/exception/detail/attribute_noreturn.hpp libs/config/include/boost/config/ git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' Move boost/throw_exception.hpp and exception.hpp into utility: mv libs/exception/include/boost/throw_exception.hpp libs/utility/include/boost mv libs/exception/include/boost/exception/exception.hpp libs/utility/include/boost/utility git submodule foreach 'git grep -l -P boost/exception/exception.hpp -- include/boost | xargs sed -i "s|boost/exception/exception.hpp|boost/utility/exception.hpp|" || echo' git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' There are now 485 edges and 64 nodes. Several libraries form an inner mesh: $ grep -P "^\s*(type_traits|mpl|detail|utility|smart_ptr|typeof)" output.dot detail->mpl detail->type_traits detail->smart_ptr detail->utility utility->mpl utility->type_traits utility->detail type_traits->detail type_traits->mpl type_traits->typeof type_traits->utility smart_ptr->type_traits smart_ptr->detail smart_ptr->utility mpl->type_traits mpl->detail mpl->utility typeof->mpl typeof->type_traits If we treat them as one element for now, we get a new graph from the rest http://steveire.com/boost/graph_with_corelib.dot http://steveire.com/boost/graph_with_corelib.png There are now 138 edges and 39 nodes Move parts of {vector_,}property_map into graph_parallel: sed '1,/BOOST_GRAPH_USE_MPI/d;/BOOST_GRAPH_USE_MPI/,$d' libs/property_map/include/boost/property_map/property_map.hpp > tmp.hpp sed -i '/BOOST_GRAPH_USE_MPI/,/BOOST_GRAPH_USE_MPI/d' libs/property_map/include/boost/property_map/property_map.hpp sed '1,/BOOST_GRAPH_USE_MPI/d;/BOOST_GRAPH_USE_MPI/,$d' libs/property_map/include/boost/property_map/vector_property_map.hpp >> tmp.hpp sed -i '/BOOST_GRAPH_USE_MPI/,/BOOST_GRAPH_USE_MPI/d' libs/property_map/include/boost/property_map/vector_property_map.hpp sed -i '/#undef PBGL_DISTRIB_PMAP/r tmp.hpp' libs/property_map/include/boost/property_map/parallel/distributed_property_map.hpp rm tmp.hpp git submodule foreach 'git grep -l -P boost/property_map/parallel/distributed_property_map.hpp -- include/boost | xargs sed -i "s|boost/property_map/parallel/distributed_property_map.hpp|boost/graph/parallel/distributed_property_map.hpp|" || echo' git submodule foreach 'git grep -l -P boost/property_map/parallel/impl/distributed_property_map.ipp -- include/boost | xargs sed -i "s|boost/property_map/parallel/impl/distributed_property_map.hpp|boost/graph/parallel/detail/distributed_property_map.hpp|" || echo' mv libs/property_map/include/boost/property_map/parallel/distributed_property_map.hpp libs/graph_parallel/include/boost/graph/parallel mv libs/property_map/include/boost/property_map/parallel/impl/distributed_property_map.ipp libs/graph_parallel/include/boost/graph/parallel/detail git submodule foreach 'git add . || echo' git submodule foreach 'git commit -am migrate || echo' http://steveire.com/boost/graph_after_parallel.dot http://steveire.com/boost/graph_after_parallel.png There are now 95 edges and 33 nodes The remaining problematic edges are: conversion->range conversion->math range->algorithm math->multiprecision concept_check->parameter Assuming they can be broken by moving some files aroung (I believe they can be), we end up with a small graph of strongly connected components: http://steveire.com/boost/graph_after_remaining.dot http://steveire.com/boost/graph_after_remaining.png There are now 18 edges and 11 nodes. Looking at the entire graph again, we get this: http://steveire.com/boost/graph_final.dot http://steveire.com/boost/graph_final_small.png Obviously, this is not perfect, but it is a beginning, and it is mostly now a directed graph. Any comments? Thanks, Steve.

29 162

[parameter] referring to argument types in BOOST_PARAMETER_FUNCTION return values
by Erik Erlandson 05 Nov '13

05 Nov '13

There is documentation that demonstrates using boost::parameter::value_type<> to extract the type of an argument in the boost::parameter library. However, the example does *not* use the BOOST_PARAMETER_FUNCTION() macro, and so the resulting function doesn't benefit from all the features you can get from that macro: Section 3.2.2: http://www.boost.org/doc/libs/1_54_0/libs/parameter/doc/html/index.html#mor… I was able to fairly easily obtain the same kind of arg type information inside of a BOOST_PARAMETER_FUNCTION() declaration, which I show in this example: https://gist.github.com/erikerlandson/7319975 To come up with that, I had to throw '-E' and examine the macro expansions to determine that 'Args' is the appropriate argument-pack template name to use. In other words, what I did doesn't appear to be officially supported: // not officially documented or supported? (typename boost::parameter::value_type<Args, tag::c, int>::type) However, I don't see any barrier to officially supporting the above. All it requires is a promise that 'Args' is the template name that will be generated by the macros. Alternatively, provide a new utility macro, such as: #define BOOST_PARAMETER_ARG_TYPE(arg_name) typename boost::parameter::value_type<[template arg name], [namespace]::arg_name, int>::type

1 0

Re: [boost] [1.55.0] Release candidate 2 available
by Sergey Cheban 05 Nov '13

05 Nov '13

On 04.11.2013 4:00, Jeff Flinn wrote: > Serialization still fails to build on VS2013. This is due to tickets #9279/#8750 > not being merged to release from trunk. Robert sent me a direct email saying > "See my previous post on this thread to see why we're stuck here." but I've not > been able to figure out to what he's referring. I see the same problem: ...failed compile-c-c++ bin.v2\libs\serialization\build\msvc-12.0\dbg\adrs-mdl-32\archt-x86\lnk-sttc\rntm-lnk-sttc\thrd-mlt\basic_text_oprimitive.obj... compile-c-c++ bin.v2\libs\serialization\build\msvc-12.0\dbg\adrs-mdl-32\archt-x86\lnk-sttc\rntm-lnk-sttc\thrd-mlt\basic_text_iprimitive.obj basic_text_iprimitive.cpp C:\Users\sch\Documents\BoostBuild\boost_1_55_0rc2\boost/archive/iterators/transform_width.hpp(151) : error C2039: 'min' : is not a member of 'std' C:\Users\sch\Documents\BoostBuild\boost_1_55_0rc2\boost/archive/iterators/transform_width.hpp(134) : while compiling class template member function 'void boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<CharType>>,CharType>,8,6,CharType>::fill(void)' ...failed compile-c-c++ bin.v2\libs\serialization\build\msvc-12.0\dbg\adrs-mdl-32\archt-x86\lnk-sttc\rntm-lnk-sttc\thrd-mlt\basic_text_woprimitive.obj... compile-c-c++ bin.v2\libs\serialization\build\msvc-12.0\dbg\adrs-mdl-32\archt-x86\lnk-sttc\rntm-lnk-sttc\thrd-mlt\basic_text_wiprimitive.obj basic_text_wiprimitive.cpp C:\Users\sch\Documents\BoostBuild\boost_1_55_0rc2\boost/archive/iterators/transform_width.hpp(151) : error C2039: 'min' : is not a member of 'std' C:\Users\sch\Documents\BoostBuild\boost_1_55_0rc2\boost/archive/iterators/transform_width.hpp(134) : while compiling class template member function 'void boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<CharType>>,CharType>,8,6,CharType>::fill(void)' basic_text_oprimitive.cpp .\boost/archive/iterators/transform_width.hpp(151) : error C2039: 'min' : is not a member of 'std' .\boost/archive/iterators/transform_width.hpp(134) : while compiling class template member function 'void boost::archive::iterators::transform_width<const char *,6,8,char>::fill(void)' ...failed updating 8 targets... ...skipped 8 targets... ...updated 1080 targets... -- Sergey Cheban

1 0

[modularization] Improving/splitting up detail
by John Maddock 05 Nov '13

05 Nov '13

Lets say we wanted boost/detail to depend on nothing but config, here's what it would take: boost/detail/algorithm.hpp Used by graph lib only, suggest it's moved there. boost/detail/allocator_utilities.hpp Used by multi index, statechart and flyweight, suggest move to new "common" module. boost/detail/atomic_count.hpp Depends on smart_ptr's details only, suggest those details are moved to "detail" module. boost/detail/binary_search.hpp Used by python and test, move to "common". boost/detail/bitmask.hpp Only external dependency is boost/cstdint.hpp, either move to "common", or else move cstdint.hpp to "config". boost/detail/call_traits.hpp Move to call_traits (should be there already). boost/detail/catch_exceptions.hpp Only external dependency is boost/cstdint.hpp, suggest latter is moved to config. boost/detail/compressed_pair.hpp Move to compressed pair (should be there already). boost/detail/endian.hpp Move to "predef" boost/detail/has_default_constructor.hpp File appears to be unused, and not very useful, suggest we remove it. boost/detail/identifier.hpp File appears to be unused, suggest we remove it. boost/detail/indirect_traits.hpp Used by iterator and python, move to "common" boost/detail/is_incrementable.hpp Move to common, or better modify the libraies using this to use the newer type_traits equivalents. boost/detail/is_sorted.hpp Used by graph and range, move to "common" boost/detail/is_xxx.hpp Used by parameter and python, move to "common" boost/detail/iterator.hpp I suspect this may be obsolete now compiler requirements have been bumped, but whatever it's still used by multiple libs: move to "common" boost/detail/lcast_precision.hpp Only used by lexical_cast, move it there. boost/detail/lightweight_mutex.hpp Only extern dependency is smart_ptr's details, suggest move those to detail. boost/detail/named_template_params.hpp Appears to be unused, suggest we remove. boost/detail/numeric_traits.hpp Used by graph and iterator, move to "common" boost/detail/ob_compressed_pair.hpp Move to compressed pair, might also be obsolete by now. boost/detail/quick_allocator.hpp Only external dependency is smart_ptr's details, suggest those are moved here. Or since only serialization uses this, move this file there... boost/detail/reference_content.hpp Used by optional and variant, move to "common". boost/detail/winapi/* Depends on boost/cstdint.hpp only, suggest that belongs to config. Everything else in detail has no dependencies other than config. Thoughts? John.

11 22

Re: [boost] [Trac] Catch-22: Captcha Errors on legitimate submissions (fwd)
by DongInn Kim 04 Nov '13

04 Nov '13

Hi, I have looked into the trac admin page to see if there is anything useful for this issue and I found that the current Jim Bell’s tickets and comments were filtered out as a spam. http://www.crest.iu.edu/~dikim/spamfilter.png The spamfilter on trac is not perfect. It just filters out anything if they meet some criteria that the filter setup. I have not setup the filter criteria (Yes, I have installed the spam filter as you guys requested). It seems that it needs to train the spam filter with some admin’s interaction on the filtered tickets as a spam or ham. I just tried to make four Jim Bell’s ticket/comments selected as a ham. I hope the spam filter does a little better job on Jim Bell’s ticket next time. The following users are the admin of the boost trac system and I hope that they need to train the spam filter from time to time in case this kind of incidents happen. az_sw_dude admin bemandawes admin dave admin dgregor admin eric_niebler admin grafik admin johnmaddock admin marshall admin -PS- I do not follow this mailing list. If someone forwards an email to me like this, I can see what happens. Regards, -- - DongInn On Nov 1, 2013, at 9:35 PM, Jeremiah Willcock <jewillco(a)crest.iu.edu> wrote: > > > ---------- Forwarded message ---------- > From: Jim Bell <Jim(a)JC-Bell.com> > To: boost(a)lists.boost.org > Date: Fri, 01 Nov 2013 18:25:01 -0500 > Subject: [boost] [Trac] Catch-22: Captcha Errors on legitimate submissions > Reply-To: boost(a)lists.boost.org > X-perlmx-spam: Gauge=X, Probability=10%, Report=' > TO_IN_SUBJECT 0.5, REPLYTO_FROM_DIFF_ADDY 0.1, HTML_00_01 0.05, > HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, > BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, > BODY_SIZE_700_799 0, DATE_TZ_NA 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __CT 0, > __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_LIST_HEADER 0, > __HAS_LIST_HELP 0, __HAS_LIST_SUBSCRIBE 0, __HAS_LIST_UNSUBSCRIBE 0, > __HAS_MSGID 0, __HAS_REPLYTO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, > __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __SANE_MSGID 0, > __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, > __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' > > I had a ticket attachment and comment both rejected from a "captcha error," so I decided to open a Trac ticket on the captcha mechanism itself. But guess what? THAT ticket was also rejected by the captcha error. Catch-22! > > So I'm posting it here. > > I get: > -------------------------------- > Captcha Error > Submission rejected as potential spam (StopForumSpam says this is spam (username)) > > Trac thinks your submission might be Spam. To prove otherwise please provide a response to the following. > -------------------------------- > > But there's nothing following to which to provide a response. Is it mis-configured? > > > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

5 4

Re: [boost] [modularization] Dependency to Boost.Exceptionunavoidable?
by Niall Douglas 04 Nov '13

04 Nov '13

On 3 Nov 2013 at 9:08, Robert Ramey wrote: > I don't think it's a great idea for a library author to make the > requirements for using his library more stringent than is absolutely > necessary. I generally agree. With the exception of features specified to be part of the C++ language standard. Those any C++ codebase has the right to assume are always available. > The way BOOST_EXCEPTION used to be was correct - Implemented as a throw if > the platform supported it, and calling some defined function if the > platform doesn't support them. This actually works well when exceptions > are not used as part of the code logic but only to handle "error > conditions". This practice is generally recommended and many follow it. > In this context, there's not reason not couple one's library to the > existence of RTTI or an related compiler feature. I think my personal difficulty here is that lack of RTTI can be worked around (e.g. Boost.TypeIndex), whereas presence or lack of exceptions means completely different design of a C++ codebase, with a non-exception safe design being utterly and more importantly permanently defective when used in the presence of exceptions - a rather important distinction. I can certainly see that by ruling out exception safety during design that one can get code to market quicker - assuming that one does not save significant implementation time by making use of libraries which assume exceptions work (e.g. the C++11 STL), because as soon as you mix in exception assuming code with non-exception capable code you have interop problems. > "it was/is an interesting choice by a large, modern, non-embedded C++ > use case." > > I think that boost should provide more support for embedded systems - not > less. I agree in the sense that hard realtime use cases for Boost where there is guaranteed worst case execution times is incredibly important, and indeed for those cases where Boost.TypeIndex can replace RTTI it will eliminate RTTI's unbounded execution times. That makes exception throwing the only unbounded worst case execution time scenario remaining. There is nothing about an embedded system that implies exceptions ought to be disabled though, especially with any semi-recent compiler and that your codebase isn't regularly throwing exceptions while it runs. You do tend to lose a register and use more stack space in code generation, but a reasonably modern bottom end embedded CPU is fairly tolerant of that nowadays thanks to having at least a L1 cache which hides a lot of the consequences of extra but unused stack usage. It's not like on 6502 with its three registers incapable of even burst read/writes to RAM for sure, or even an ARM v2 where stack writes across RAM page line boundaries stalled the CPU. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

1 0

[1.55] Request for permission to merge fix for chrono.
by Vicente J. Botet Escriba 04 Nov '13

04 Nov '13

Hi, I would like to merge if possible this fix https://svn.boost.org/trac/boost/changeset/86547 for this bug https://svn.boost.org/trac/boost/ticket/9337 . The bug was introduced on [75920] <https://svn.boost.org/trac/boost/changeset/75920>, so long time ago :( Please let me know. Vicente

3 4

Re: [boost] [modularization] Improving/splitting up detail
by Ahmed Charles 04 Nov '13

04 Nov '13

Then call them modules, tell users that libraries are made of modules and that's it. The fact that most libraries have a module called core or detail that is shared with most other libraries is utterly irrelevant to users. The fact that this allows them to use libraries while downloading and installing less other libraries is useful. ________________________________ From: Daniel Pfeifer Sent: 11/2/2013 12:23 AM To: Boost Developers List Subject: Re: [boost] [modularization] Improving/splitting up detail 2013/11/2 Ahmed Charles <acharles(a)outlook.com>: > > >> Date: Fri, 1 Nov 2013 22:34:07 +0000 >> From: daniel(a)calamity.org.uk >> To: boost(a)lists.boost.org >> Subject: Re: [boost] [modularization] Improving/splitting up detail >> >> On 1 November 2013 22:10, Daniel Pfeifer <daniel(a)pfeifer-mail.de> wrote: >> >> >> >> boost/detail/xxx.hpp >> >> >> >> Used by YYY and ZZZ, move to "common" >> > >> > Isn't there already a dependency from YYY to ZZZ? Could we put xxx.hpp >> > to ZZZ instead? Maybe a "common" is not even needed. >> >> We should be careful about making changes just because they fit the >> current dependencies. Dependencies are not constant, we don't want to >> be in a situation where the dependency graph falls apart because of a >> future change to one of these headers. Also, if a header is in detail >> it should be potentially useful for future libraries which wouldn't >> want to depend on ZZZ (if it isn't, then it shouldn't have been put in >> detail in the first place). > > The goal is to create two 'modules' or libraries: We had that originally. They were called "detail" and "core". How do we describe those libraries to users? Those might be the Frequently Questioned Answers: A: It is a Boost library that you should not use. Q: If it is not useful, why does it exist? A: It is used internally by several Boost libraries. Q: If it is so useful, why should I not use it too? I prefer to have no such "detail" libraries at all. Everything that is useful to a broader audience should be in utility. Everything else should be an implementation detail of one library. When one library depends on the implementation detail of another library (ie. includes a 'detail' header from it), that is a smell, OK. But at least it is hidden from users. -- Daniel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

[config] clang deleted functions bugged
by Vicente J. Botet Escriba 04 Nov '13

04 Nov '13

Hi, Clang has a bug with deleted functions (see http://stackoverflow.com/questions/7754564/clang-error-message-when-using-c…) Please, could we comment these two lines until clang fixes the bug //#if !__has_feature(cxx_deleted_functions) # define BOOST_NO_CXX11_DELETED_FUNCTIONS //#endif Thanks, Vicente

3 8

Re: [boost] [Boost-users] [1.55.0] Release candidate 2 available
by Tom Kent 04 Nov '13

04 Nov '13

On Sun, Nov 3, 2013 at 6:00 PM, Jeff Flinn <Jeffrey.Flinn(a)gmail.com> wrote: > On 11/3/2013 6:05 PM, Marshall Clow wrote: > >> >> On Nov 3, 2013, at 2:25 PM, Tom Kent <lists(a)teeks99.com >> <mailto:lists@teeks99.com>> wrote: >> >> On Sun, Nov 3, 2013 at 3:15 PM, Marshall Clow <mclow.lists(a)gmail.com >>> <mailto:mclow.lists@gmail.com>> wrote: >>> >>> RC2 files for 1.55.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, and anything else that is noteworthy. >>> >>> This helps ensure the candidates build OK before we push them out >>> to SourceForge. >>> >>> The files (and associated md5s) are: >>> 93780777cfbf999a600f62883bd54b17 >>> *boost_1_55_0_rc2.tar.gz >>> d6eef4b4cacb2183f2bf265a5a03a354 >>> *boost_1_55_0_rc2.tar.bz2 >>> 8aca361a4713a1f491b0a5e33fee0f1f >>> *boost_1_55_0_rc2.zip >>> 4e5bbc15fc8c80df8be428f8a5b5a823 *boost_1_55_0_rc2.7z >>> >>> >>> Thanks! >>> >>> -- The release managers >>> >>> >>> When is the release expected? (How long do we have to try building?) >>> >> >> We try to ship an RC on Wednesday, then release on Monday. >> If there are no problems found in this RC, I expect we'll release on >> Friday or Saturday. >> > > Serialization still fails to build on VS2013. This is due to tickets > #9279/#8750 not being merged to release from trunk. Robert sent me a direct > email saying "See my previous post on this thread to see why we're stuck > here." but I've not been able to figure out to what he's referring. > > Jeff I'm also seeing the serialization failures with msvc-12.0. Tom

2 1