May 2013 - Boost - lists.preview.boost.org

Boost build broken on the trunk
by Edward Diener 11 May '13

11 May '13

After getting the latest Boost from the trunk, and after running bootstrap I try '.\b2 install --prefix=c:\programming\bin' and get: ---------------------------------------------------------------------- Performing configuration checks - 32-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : no - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - message-compiler : yes - gcc visibility : no - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. warning: No python installation configured and autoconfiguration note: failed. See http://www.boost.org/libs/python/doc/building.html note: for configuration instructions or pass --without-python to note: suppress this message and silently skip all Boost.Python targets - zlib : no (cached) C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:1099 : in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pc:\programming\bin\lib>libboost_date_t ime-vc110-mt-gd-1_54.lib error: previous virtual target { common%common.copy-libboost_date_time-vc110-mt- gd-1_54.lib.STATIC_LIB { msvc%msvc.archive-libboost_date_time-vc110-mt-gd-1_54.l ib.STATIC_LIB { msvc%msvc.compile.c++-gregorian\greg_month.obj.OBJ { gregorian/g reg_month.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\greg_weekday.obj.OBJ { g regorian/greg_weekday.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\date_generat ors.obj.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./install-proper-lib-static error: another virtual target { common%common.copy-libboost_date_time-vc110-mt-g d-1_54.lib.STATIC_LIB { msvc%msvc.archive-libboost_date_time-vc110-mt-gd-1_54.li b.STATIC_LIB { msvc%msvc.compile.c++-gregorian\greg_month.obj.OBJ { gregorian/gr eg_month.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\greg_weekday.obj.OBJ { gr egorian/greg_weekday.cpp.CPP } } { msvc%msvc.compile.c++-gregorian\date_generato rs.obj.OBJ { gregorian/date_generators.cpp.CPP } } } } error: created from ./install-proper-lib-static error: added properties: <log-api>winnt error: removed properties: <log-api>generic C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:484: in actualize-no-scanner from module object(file-target)@4017 C:/Programming/VersionControl/boost/tools/build/v2/build\virtual-target.jam:134: in class(a)virtual-target.actualize from module object(file-target)@4017 C:/Programming/VersionControl/boost/tools/build/v2\build-system.jam:720: in load from module build-system C:\Programming\VersionControl\boost\tools\build\v2/kernel\modules.jam:289: in im port from module modules C:\Programming\VersionControl\boost\tools\build\v2/kernel/bootstrap.jam:139: in boost-build from module C:\Programming\VersionControl\boost\boost-build.jam:17: in module scope from module ------------------------------------------------------------------------ This is on Windows but the same thing occurs on my Linux distros. Cannot this be fixed ? I posted the same message for Linux failure on the Boost Build mailing list but received no response.

3 4

[bootstrap/1.53] jam0.exe crashes when bootstrapping for VC2012 AMD64
by rjeczalik 11 May '13

11 May '13

Hi, I'm trying to build Boost 1.53 using VC2012 amd64 (toolset=msvc-11.0 address-model=64) and Windows Server 2012 Standard. Bootstrapping fails with jam0.exe crash - some crash info: Crash stacktrace: ntdll.dll!000007f9bc781069() KernelBase.dll!000007f9b978764e() KernelBase.dll!000007f9b97d3658() jam0.exe!_findnext64i32(__int64 hFile, _finddata64i32_t * pfd) Line 165 jam0.exe!file_dirscan(_object * dir, void (void *, _object *, int, __int64) * func, void * closure) Line 180 jam0.exe!builtin_glob(frame * frame, int flags) Line 718 jam0.exe!function_run(_function * function_, frame * frame, _stack * s) Line 3390 jam0.exe!evaluate_rule(_object * rulename, frame * frame) Line 264 jam0.exe!function_call_rule(_jam_function * function, frame * frame, _stack * s, int n_args, const char * unexpanded, _object * file, int line) Line 468 jam0.exe!function_run(_function * function_, frame * frame, _stack * s) Line 3950 jam0.exe!parse_file(_object * f, frame * frame) Line 57 jam0.exe!main(int argc, char * * argv, char * * arg_environ) Line 488 jam0.exe!__tmainCRTStartup() Line 241 jam0.exe!mainCRTStartup() Line 164 kernel32.dll!000007f9b9de167e() ntdll.dll!000007f9bc7a3501() Line where it crashed was: if (!FindNextFile((HANDLE)hFile, &wfd)) { I've tried to watch the values of arguments passes to FindNextFile() - hFile looked like proper handle, however wfd.cFileName and wfd.cAlternateFileName contained garbage. Is this a known issue for 1.53? I've compiled version 1.52 using the same environment and the same configuration and everything went ok, I did not manage to reproduce the crash. It looks like only version 1.53 is affected. Regards, Rafael Jeczalik

5 5

Re: [boost] [log] Patch: rotating file collector
by Andrey Semashev 10 May '13

10 May '13

On Tue, Apr 23, 2013 at 3:58 PM, Alexander Arhipenko <arhipjan(a)gmail.com>wrote: > > I've added implementation of rotating file collector - > the patch against boost log trunk attached. > This is not the final version, I'm going at least to finish most of the > TODOs. > > However, it would be nice to receive feedback and questions from > library author as well as from people interested in this feature. > > Andrey, could you please find several minutes to review the attached patch? > Thanks for the patch. I didn't look deeply into it yet but from the first glance it looks like you changed the existing file collector rather than introduce an alternative one. Am I right? If so, could this be made as a pure addition rather than modification? I would prefer to keep the current behavior also available for the users. Also, I would like to discuss following question with you : > rotate_file invocation in ~text_file_backend - > I would prefer to have this call during text_file_backend construction > phase. > I'll have to take a closer look later to answer that but it seems odd to have to rotate something when nothing have been written yet. The rotate_file call is intended to place the written file to the storage governed by the collector, and at construction this file hasn't been created yet. Could you describe why you need this?

3 7

[algorithm] More general purpose algorithms?
by Sai Kiran Talamudupula 10 May '13

10 May '13

Hi, I am new to using boost libraries. I want to contribute to [boost.algorithm]. I see that there is scope for adding more general purpose algorithms in the library now. If I might have some ideas, is this the right place to propose and discuss them? Do I need to follow any procedure and/or address a specific person? Best, Saki.

2 1

Wanted: reviewers for boost.test doc overhaul
by legalize+jeeves＠mail.xmission.com 10 May '13

10 May '13

[Please do not mail me a copy of your followup] As per the "What do we do about boost.test?" thread last year, the biggest complaint seemed to be the documentation. I'm overhauling the documentation using quickbook and I'd appreciate incremental feedback along the way. Any takers? -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

5 4

Re: [boost] [TypeErasure] references
by Felipe Magno de Almeida 10 May '13

10 May '13

On Mon, Jul 30, 2012 at 2:51 PM, Chapman, Alec <archapm(a)fas.harvard.edu>wrote: > On 7/26/2012, 5:45 PM, Chapman, Alec wrote: > > > The problem is that there are significant differences between > > > references and values. This is okay for Boost.Function, because > > > Boost.Function doesn't expose ant mutating operations. However, in > > > the more general case this behavior is too error prone. Just think > > > about what would happen if we allowed using boost::ref for > > > any_iterator. Some Algorithms assume that they can make copies of > iterators > > and that these iterators are independent of each other. > > > > These are exactly the sorts of algorithms I have in mind. What I am > suggesting > > is that the original object is held by reference, but when a copy is > made the > > underlying object is copied as well. With your method I do not see a > way to > > capture by reference and then pass that object to an algorithm that does > not > > have special logic to handle Boost.TypeErasure. > > > > Perhaps the false parallel with Boost.Function would be confusing. I > have also > > done it by overloading the constructor with a dummy parameter: > > > > int i = 0; > > any<requirements> x(i, type_erasure::as_reference); // x holds a pointer > to i > > any<requirements> y(x); // y allocates a new > > integer and initializes it with i > > ++y; // i is still 0 > > > > Hi Steven, > Have you had a chance to consider this? Please let me know if something > I'm suggesting isn't clear or if there is already a way to achieve this > with your library. > I also need something like this. I don't see much difference from using boost::ref and defining my copying and value semantics to not take the attributes into account as my documented semantics So I really don't see what the problem is. While algorithms might get confused, this is directly related to the semantics given, which might be different from type to type that is erased. That is no difference, to me, from creating a specific wrapper with different copying semantics. Your argument about any_iterator is valid because a forward iterator that doesn't save its position is not a forward iterator at all, but that's not true for all concepts. And using boost::ref by the user and implementing a non-ForwardIterator directly is no different. And creating specific wrappers will be a pain for these concepts that allow the implementation to use pointer/references. Using the _self& is no use for these concepts, since the whole point is to type erase, having multiple types to implement the same concept with a type-erased interface won't scale at all. Support for smart pointers and naked pointers would be a great plus as well. > Alec > Regards, -- Felipe Magno de Almeida

2 2

Re: [boost] Git Modularization Ready for Review
by Niall Douglas 09 May '13

09 May '13

> > I'm far more confused as to why? Surely the conventional approach is to > > convert a SVN repo to GIT. > > Good luck with that, given the way SVN "branches" (really directories) > have been used in Boost's history. No automated tool is able to > determine how to map those things properly onto Git branches. You can > see evidence of that in repositories.txt (look at the "build" repository > declarations for example). Me personally I'd just chuck away any unmappable historical information. Chalk it up to a cost of transition. If they really need the history, they can go fetch it from the read-only SVN repo. > You act as though we haven't been thinking about how to do this well and > working on it for years already. We're quite well-aware how submodules > work. The use of submodules by most developers is supposed to be a > temporary transitional measure, since modularization is designed to > allow you to work with only the parts of Boost relevant to your project. You have mistaken my confusion for criticism. I am not criticizing. I am confused. > > Also, how is Boost going to manage dependency breakage across multiple > > submodules? > > What is "dependency breakage?" Generally speaking Git submodules are for loosely coupled relations because of how Git implements submodules. Some of Boost's constituent libraries do meet that definition (BPL, BGL, Math). Some do not, as they are too essential because so many other libraries depend on them (anything likely to enter the standard with TR2, the MPL, the PPL etc). I fear that if modularization is taken to its logical extreme, you could see submodules get out of step with other submodules. You may of course have already anticipated this and have implemented something I haven't realized. As I said, I am confused. > > Are you planning to keep headers in one monolithic repo > > No > > > but keep anything resulting in a DLL/SO in a submodule? Or are you > > planning to break out the headers into submodules too? > > Yes; it's already done, modulo some expected adjustments due to the > review I am requesting. One solution is to require all findable headers to live inside the main Boost repo [1], and only implementation to reside in submodules. That keeps minds focused on dependency management. [1]: By findable I mean that when Boost library users do #include <boost/whatever> they get the main Boost repo version, not the submodule version. I absolutely would expect an automated tool to pull headers from submodules, check them for ABI breakage and push them into the main repo. My point is that some sanity check ought to be there. > > I can see it becoming quite easy for submodules or branches or forks > > thereof to get out of step with one another. > > That's a *good* thing. We're trying to decouple. Most libraries will > be developed against the previous release of their dependencies. > > > I can see the present submodule heavy approach introducing a lot of > > anti-Git workflow because those submodules inside the boostorg > > organization are treated as special compared to other submodules. > > I don't have any idea what you mean here Git generally has you clone the authoritative master repo, you create a branch, make your changes. Once you're finished, you fetch latest master, merge into your branch until it's up to date, then generate a patch or pull request from your branch to authoritative master. Whoever gatekeeps that repo does the merge. Where I'm getting confused - again - is that it would seem that the submodule repos inside the Boost org section on github are the ones to be regression tested and used to assemble releases. So, instead of treating all git repos as one-among-many as say Linux would do, we've got a special "high" gold candidate set of git repos and then all other git repos. This appears to add an extra layer of syncing and merging, because surely Boost admin has the power to modify any of the high gc set of repos. I'm not saying that this choice isn't for very good reasons. It's just that from my experience a submodule heavy git repo with lots of tightly coupled submodules becomes a royal PITA for end users because you get all sorts of weird obtuse breakages for apparently no reason at the time. Maybe of course it's just me, and I have some mental block others don't have. And I absolutely agree that other projects such as KDE have adopted your approach and it seems to work for them. However Boost is not KDE. In my mental model of the world, Boost more resembles the Linux kernel in terms of interdependencies and size. KDE has a vastly more stable intra-module ABI and much more loosely coupled submodules. This interpretation may be a mistake of mine. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

2 1

Re: [boost] The file boost/detail/endian.hpp needs to be set up for your CPU type
by Niall Douglas 09 May '13

09 May '13

> > How does one write a proposal to the C++ committee? > > http://isocpp.org/std/submit-a-proposal > > > I'll do it. This is a > > problem that probably comes up a lot, people then figure out some > > clumsy workaround and then forget about it. These workarounds are > > just that, and they impact the bottom line as programmers try and > > figure out some way of figuring them out. > > > > This should be standard. No workaround required. > > Jonathan hit the nail on the head.The C++ standard is essentially an open source > software project staffed entirely by volunteers. There is no such thing as > something that "should be standard" - there are only things that someone has > written a proposal for, and then gone to the trouble of shepherding through the > standardization process. Also, allocate a minimum of at least one year to achieve a successful shepherding, and that's for an obvious, uncontroversial change. ISO standards has large barriers to entry and for good reason: only those with stamina and the ability to repeatedly rewrite proposals to correctly include feedback will succeed. I'm not saying don't do it, because if there's a problem it should be fixed. I am saying that most of the work in writing a proposal isn't in writing and submitting one as that part is straighforward, it's in the shepherding part as Beman points out. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

The file boost/detail/endian.hpp needs to be set up for your CPU type
by Adrian_H 09 May '13

09 May '13

I saw this error and was wondering, can the endianness of a compiler not be determined through templates instead of using <endian.h>? Using macros seems to be pretty old-school and if headers are not updated could be just flat out wrong. -- View this message in context: http://boost.2283326.n4.nabble.com/boost-The-file-boost-detail-endian-hpp-n… Sent from the Boost - Dev mailing list archive at Nabble.com.

7 14

Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
by Niall Douglas 09 May '13

09 May '13

> IIUC, the question is related to Qt's API for integrating with Qt's event > dispatcher, which (IIUC again:p) is used by QApplication, QCoreApplication and > QThread. > > Apologies if I'm off target here. Correct. I think the gold standard is a thread pool implementation which seamlessly allows Boost.ASIO to be combined with Qt's event dispatcher all in the single implementation. In other words, the thread pool can cope with multiple simultaneous event dispatcher implementations. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0