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

[GSoC] HTTP library traits
by Vinícius dos Santos Oliveira 21 May '14

21 May '14

Hi, I've been working on the HTTP library that will later be proposed to inclusion on Boost. I still don't have a working example to show and some uncommited and incomplete changes to documentation generation (still learning QuickBook) and changes to the acceptor (don't bother to ask) are laying around on my system. I can hunt all these on my all and I'll ask for design ideas later. The reason for this email is to ask for help from template meta programming ninjas to rate the skel of my traits implementation. It took me a whole day (first time I had the opportunity to play with SFINAE) to write this and I don't know if I'm following good practices or so on: - https://github.com/BoostGSoC14/boost.http/blob/b9c596249e39eea26fe1b59377cc… - https://github.com/BoostGSoC14/boost.http/blob/b9c596249e39eea26fe1b59377cc… -- Vinícius dos Santos Oliveira https://about.me/vinipsmaker

2 3

(Fwd) Re: Thoughts on Boost v2 (was: Re: Is Boost dead? [Re: Anyone is interested in being review manager of ‘Applic
by Niall Douglas 21 May '14

21 May '14

And the other one, probably the one people actually wanted .. N ------- Forwarded message follows ------- Date sent: Mon, 19 May 2014 10:04:22 -0700 (PDT) From: Robert Ramey <robertmacleranramey(a)gmail.com> To: boost-devel-archive(a)googlegroups.com Copies to: boost(a)lists.boost.org, boost(a)lists.boost.org, s_sourceforge(a)nedprod.com Subject: Re: [boost] Thoughts on Boost v2 (was: Re: Is Boost dead? [Re: Anyone is interested in being re view manager of `Application´?]) Ahhhh - not only provocative but actually concrete enough to comment on: Here goes On Friday, May 16, 2014 10:10:51 AM UTC-7, Niall Douglas wrote: > > > 2. Everyone recognises there are serious problems with process, > everything from how you were treated Stephen when you tried cleaning > out cruft and only really Dave supported you, This effort may have been well intended - but is ill conceived and had major flaws in approach and execution. I don't want to re-debate this here so let's just agree to not use this as an example of anything. right through to the > fact that peer review simply doesn't work any more. There is wide agreement that there are problems here. The boost library incubator (www.blincubator.com) is a major effort to address this. We'll see if this helps. The Boost > community has become quite selfish in recent years, as you would > expect from those with a vested interest in the status quo before > evolution. And for the record, I have no problem with those vested > interests keeping their existing Boost, It's hard to attribute motives to a person - much less than an organization. > but I personally want as far away from C++ 03 as soon as is possible. > Not everyone has that luxury. 3. All the interesting new C++ 11 libraries you find around the > internet have zero interest in trying to join Boost, with a very few > honorable exceptions. That speaks volumes, to me at least. > Without seeing a list of these, it's hard to comment. Which suggests to me a need for a new Boost which attempts to apply > the benefits of hindsight to what we learned with Boost v1. Hmmm - not to me. Note that the problem of various C++ versions has existed since the beginning of boost. Not differing standards but no compiler implement the whole standard and all had bugs. This was addressed by a couple of things. a) Boost.Config which abstracted all the platforms to a common interface. b) An explicit policy that no library be required to be backward compatible or be compilable by any buggy or out of date platform. Many authors have made their libraries backward/buggy compatible in the interests of getting wider usage - but that has not been a boost requirement. c) Though it has not been explicitly stated, (maybe it should be) all libraries should be (and I believe they are) build able and testable with any compiler which meets the latest standard. Now, it > is extremely clear from this conference there is little appetite for > that, but I think later on this year we're going to have three C++11 > libraries in the queue, no problem. And here is what I think should be in a fork of Boost: > A fork of boost would be a spectacularly bad idea - it would mean the end of boost as we know it. > 1. Minimum required compiler feature set will be VS2014's. Hmm - I'm not sure what this means. I believe that all libraries current build and test under the latest C++ compilers. > No use of Boost STL permitted where the C++ 11 STL provides a feature. > This is for the library review process to determine. 2. cmake instead of Boost.Build. There is mixed history regarding boost tools. In some cases things have worked well other cases less so. A big problem is that boost has imposed which tools must be used. It seems you're comfortable with this - but just thing the tool choices need to be updated. I think this is the wrong approach has has contributed to our recent difficulties in evolving to the current software development landscape. I believe we will eventually want to pull back from tool selection specifics and move toward specifying tool requirements. More less like the boost documentation toolset situation. There is no specific requirement as far as toolset but it's wide agreed that documentation is required and that meet some sort of standard. (though that standard hasn't really been explicitly defined - we all think we know what it is). > 3. Eliminate peer review in favour of a suite of automated libclang > based AST analysers. Instead of persuading people to review > libraries, persuade them to review and improve the AST analysers. > I'm trying to restrain myself, but this idea is so naive as to be ridiculous. 4. Mandatory cross platform per-commit CI with unit testing exceeding > 95% coverage. We don't care what unit test library is used so long as > it can output results Jenkins can understand. > These kinds of mandates are a bad idea. No one can predict the future with the precision necessary to make them. > > 5. Mandatory all green thread, memory, UB sanitisers and clean > valgrind. All also tested per-commit. > lol - see above. > 6. Mandatory CI testing for exception safety. I am hoping a clang > rewriter can basically patch all exception throws and have them > randomly throw for testing. > again - not realistic given our variety of environments. > 7. Per-library source distributions instead of a monolithic blob. > This implies some dependency management, I agree with this. Though the scale of the effort seems way under estimated - as usual > but cmake makes that much easier. CMake is not nearly up to this job. In fact, I haven't seen any tool that can actually work for dependency management in our context. Actually, other than John Maddocs post on the problem), I haven't seen any posts which demonstrate an understanding of the problems with this. > It also means we can eliminate the release cycle because each > library does its own release cycle, OK - we've got that now with modular boost whenever anyone merges their develop branch to master. We do need to agree on per library versioning scheme though. and the correct (i.e. tested) > version of dependencies are included into each per-library source > distro. This is never going to be all that reliable. This solves the version lock problem currently plaguing > git-ised Boost, at the cost of pushing the version lock problem onto > users [1]. I don't know what this means. > BTW I want to see a soak test of the unit tests for 24 > hours be all green before a release. > For now I would say that a Boost Release would be: a) All master branches would be tagged with Boost.1.xx b) All tests are run on this branch - if everything passes that Boost 1.xx become the release and git export is used to create the tar, zip, et This purpose of this is catch errors where some library has changed it's interface and broken any dependent libraries. I think (though I'm not sure) that this is inline with your idea above > > 8. Reusable utilities in a submitted library need merging into some > common utilities library which follows the STL conventions. Other > than that, no source code, naming conventions, namespace or anything > else needs converting or changing. We are looking for very high > quality C++ libraries, nothing more. Obviously if someone hopes for a > library to enter the C++ 17 STL they'll need much more rigour, but > that's up to them. > I don't understand what you're getting at here. But .. I think we will evolve a classification scheme which distinguishes levels of dependency a) std b) boost::core e.g. config, mpl c) boost::application e.g. odint, seriaiization? Basically to be able keep out circular dependencies and depency explosion. 9. There is no longer an "in" or an "out" for distribution. I'm > thinking of a scorecard page where member libraries are ranked by how > high quality they are according to all the automated review, so when > I say "mandatory" above, I simply mean they don't get to appear on > the main downloads page without that precondition. All submitted > libraries do appear though, just ranked very low if their quality is > low. I would hope all this is generated from a database and requires > very little human input. > This has merit but the explanation isn't concrete enough. Here's my take on this. Boost has a number of aspects a) lists and communication and community b) library certification via reviews and acceptance c) creation of a monolithic "product" c) testing d) deployment. In the future I would expect to see something different a) community - same as above b) library certification via reviews and acceptance - same as above. c) deployment of closed subset. subsets would be selected either by users when they download (e.g. cygwin) or by third parties (e.g. some embedded systems vendor includes a subset with his IDE). Hopefully boost could then better focus on what only boost can do - certify some specific level of quality. 10. BoostBook documentation using the Boost look and feel becomes > mandatory. I've had enough with library authors thinking they can > improve on BoostBook's output with things like using Comic Sans as > the font or weird colour schemes throughout. > LOL - i hear you. But it's not a great idea to make a big deal about this stuff. We can't really do a good job and we would spend huge amounts of time on trying agree on stuff which is less important. To grow boost has to narrow it's focus - not expand it. > So, basically, in some areas requirements are significantly > tightened. In other areas requirements are significantly loosened. > The aims of the above ten items are as follows: > > 1. To reduce the amount of human work involved in maintaining Boost. I think your specific suggestions would expand the amount of work required to maintain a working boost by a very large amount. Actually just agreeing on what to do would be huge. And it would result in bad decisions being taken since only a few could have the time to participate. What Dave and Daniel had to do for the git conversion last year was > far above what anyone should ever feel they need to do. > lol - right - should we have not made the conversion? > > 2. To decentralise Boost, letting it scale up far better. > Correct. 3. To provide a gradual process of entering Boost which authors can > tip away at slowly with automated scripts slowly improving their > rankings instead of the current "lumps" of high intensity output and > the review approved/failed scheme currently used. > Not clear what you mean - But If you look at the Boost Library Incubator it has exactly that idea. Reviews can accumulate until it becomes clear that a library should be accepted or rejected. It doesn't replace the final review. Maybe someday it might, but I doubt it. 4. To incentivise authors to maintain their libraries as the quality > bar is improved - the automated scripts will start to drop library > rankings as the quality is raised, thus dropping that library in the > overall rankings. Rather more importantly, it provides a natural > "deprecation" mechanism, something sorely lacking in my opinion from > present Boost. > This is also on the right track. I think the idea of a "deployment subset" as stated above will address this. Eventually I expect that some libraries (e.g. those which have std equivalents) would be dropped from standard deployments. They would still be approved boost libraries though. I would deprecate the word "deprecate" as it has a perjorative flavor. But rather characterize these libraries as "not part of standard (or minimal or core, or...) deployment. That, the set of deployed libraries would not be the same as the set of "boost certified" libraries as it is now. In fact, I'd like to see boost get out of the deployment business all together eventually. Robert Ramey > > Thoughts? > > [1]: If this model proves popular as we can get a regular donation > stream going, we could deploy an automated SHA stamper which through > unit test iteration, figures out which SHAs in which combinations of > libraries are compatible. Then you could safely mix library A's > distro with library B's distro. I'd imagine Debian upstream et al > might be coaxed into providing for this as they need one unified set > of compatible libraries. > > Niall > > -- > ned Productions Limited Consulting > http://www.nedproductions.biz/ > http://ie.linkedin.com/in/nialldouglas/ > > > ------- End of forwarded message ------- -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

(Fwd) Re: Thoughts on Boost v2
by Niall Douglas 21 May '14

21 May '14

Seeing as the original did not reach the mailing list. N ------- Forwarded message follows ------- Date sent: Wed, 21 May 2014 07:02:20 -0700 (PDT) From: Robert Ramey <robertmacleranramey(a)gmail.com> To: boost-devel-archive(a)googlegroups.com Copies to: boost(a)lists.boost.org, boost(a)lists.boost.org, s_sourceforge(a)nedprod.com Subject: Re: [boost] Thoughts on Boost v2 On Wednesday, May 21, 2014 4:49:37 AM UTC-7, Niall Douglas wrote: > > > > We welcome C++14 libraries and I see no problem with a submission on > > that basis alone if it is supported by at least two compilers. > > For me personally, I would vote for an instant rejection for any > library not compilable to the MSVC ABI irrespective of any other > factors. FYI a review is not a vote. Acceptance/Rejection is not a democratic process. The review manager has the authority to accept/reject based on his assessment of the quality of the library independent of the number of "votes" it receives. Long standing boost policy is that there is no explicit requirement that any code conform to any specific compiler as long as it complies with the current standard. There is no requirement that it use specific features (e.g. from more recent standards) to the exclusion of more traditional (albeit still conforming) features. Indeed, a number of libraries have been submitted and accepted that don't compile on multiple compilers. Robert Ramey ------- End of forwarded message ------- -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Boost contributing tutorial (GitHub)
by Adam Wulkiewicz 21 May '14

21 May '14

Hi, I prepared a tutorial about the contributing at GitHub/Boost describing how to create a Fork of a library, use it inside modular Boost and create a pull request. The tutorial presents examples for Boost.Geometry but could be extended to the other libraries. It has a form of a README of this repository: https://github.com/awulkiew/temp-contributing Would you be so kind and see if everything is ok wth it? In praticular I'd like to hear if this model is good for modular Boost in general? Regards, Adam

3 5

[smart_ptr] Proposal to add new memory order constants
by Andrey Semashev 21 May '14

21 May '14

Hi, I have a proposal to add new constants to the memory_order enum: memory_order_hle = 16, memory_order_hle_acquire = memory_order_hle | memory_order_acquire, memory_order_hle_release = memory_order_hle | memory_order_release These constants can be used to support Intel HLE (Hardware Lock Elision) [1] in Boost.Atomic and then reused by Boost.Sync. The meaning of these constants is Intel-specific (for now): the memory_order_hle_acquire operation has memory_order_acquire ordering and also starts a transaction; memory_order_hle_release operation has memory_order_release ordering and also commits the transaction. On other targets memory_order_hle flag is ignored and memory_order_hle_acquire and memory_order_hle_release are equivalent to memory_order_acquire and memory_order_release, respectively. The support for these constants can be implemented in the following Boost.Atomic backends: - all x86 assembler-based backends. - gcc __atomic* builtins support __ATOMIC_HLE_ACQUIRE and __ATOMIC_HLE_RELEASE flags (at least, gcc 4.8 and Intel compiler 14.0.3 for Linux). - MSVC x86_64 supports Interlocked intrinsics with _HLEAcquire and _HLERelease suffixes. There are also _Store_HLERelease, _Store64_HLERelease and _StorePointer_HLERelease. Unfortunately, these only cover 32 and 64-bit types, for other types regular atomics will be used (i.e. HLE won't be used). For 32-bit x86 asm blocks are also a possibility; all types can have HLE support. BTW, maybe Boost.Atomic is a better place for memory_order.hpp? What do you think? [1] https://software.intel.com/sites/products/documentation/doclib/stdxe/2013/c…

2 7

[filesystem] Request for comments on proposed relative() function
by Beman Dawes 20 May '14

20 May '14

There are two open tickets requesting a relative() function, and also a National Body (I.E official) comment against the Filesystem TS (which is due to finalize at the June C++ committee meeting). The committee's Library Working Group has indicated they would like to add such a function. With help from Jamie Allsop, I've put together a proposal. See attached for docs. See https://github.com/boostorg/filesystem/tree/feature/relative for a branch of filesystem with the implementation and some relative() tests added. Comments appreciated. --Beman

9 37

Viewing the group via http://post.gmane.org misbehaving again.
by Vladimir Batov 20 May '14

20 May '14

For example, Edward's thread (started May 12th) [boost] Boost review of the 'convert' library starts tomorrow May 21 shows only 2 messages in post.gmane.org. Google https://groups.google.com/forum/#!topic/boost-developers-archive/40it9qkZUhA show all 6 messages. I see the same problem -- missing messages -- in other convert-related threads that I follow.

3 2

Re: [boost] Is there any interest in a library for actor programming? serialization + uniform names
by Charousset, Dominik 20 May '14

20 May '14

The serialization and uniform name really boils down to the uniform_type_info class: Uniform names are simply a necessity if you need to identify a type based on its name. The goal is to send any kind of value to a remote machine and being able to deserialize it. If you have platofrm-independent names, you can simply prefix the binary serialized value with its type name and then get the RTTI (uniform_type_info) from the type name and deserialize the rest of the data. Boost.Actor is a bit more cleverer than that and maintains a list of type ids for each node it's connected to. Whenever you send a message with a type you didn't use beforehand, you send the type name along with its newly generated, unique ID and only use that ID going forward. But that's just an optimization. When talking about stateless communication (e.g. UDP), you can't do this and have to generate self-consistent messages. The fact that we even have to do this, is because std::type_info::name() is utterly useless. It returns a mangled name on GCC/Clang and a more sophisticated version of the type name on MSVC. The uniform name is the type name as it appears in code. So the first part of generating the uniform name is to demangle the platform-dependent name (https://github.com/Neverlord/boost.actor/blob/master/src/demangle.cpp) After that, we need to decompose the whole thing and make sure that qualifiers are always in the same order etc (https://github.com/Neverlord/boost.actor/blob/master/src/to_uniform_name.cpp) All this really is only aiming at having at type_info that is actually useful, i.e., name() returns *the exact same string* on each platform and it provides you with an interface for (1) generating values, (2) serializing and deserializing values, and (3) compare values. When generating a value through an uniform_type_info, you'll get a uniform_value, which is bascially a wrapper keeping {uniform_type_info*, void*}. Since we need a way to pass a serializer to a uniform_type_info instance, we can't use a templated approach as the archives in boost.serialization. The serialization classes in use (https://github.com/Neverlord/boost.actor/blob/master/boost/actor/serializer…) operate on sequences and primitive types. With the begin_object member function you also have a way of define serialization recursively, but I don't know if it's really needed to be honest. The write_tuple member function is probably not needed either, since you can simply just write the values one by one. However, it does give you a way of grouping values representing a single member together, which can be quite helpful when serializing to strings for instance. By the way, each announced type in Boost.Actor implicitly has a to_string(), which simply passes the value to a string serializer. There's also a from_string() that passes the input to a string deserializer, which gives you a simple way of injecting messages to the system. But the whole string serialization is not really fleshed out and the format not well defined. ________________________________________ From: Boost [boost-bounces(a)lists.boost.org] on behalf of Hartmut Kaiser [hartmut.kaiser(a)gmail.com] Sent: Tuesday, May 13, 2014 20:46 To: boost(a)lists.boost.org Subject: Re: [boost] Is there any interest in a library for actor programming? serialization + uniform names I'd be interested in hearing more details about this. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > -----Original Message----- > From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrzej > Horoszczak > Sent: Tuesday, May 13, 2014 8:16 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Is there any interest in a library for actor > programming? serialization + uniform names > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 5

Call for Review: Boost.Test documentation rewrite
by legalize+jeeves＠mail.xmission.com 19 May '14

19 May '14

[Please do not mail me a copy of your followup] Boost.Test documentation rewrite: <http://user.xmission.com/~legalize/tmp/boost.test/libs/test/doc/html/> Please post all comments to this list. I've been working on this as time permits for a number of months and I think now things are "finished" enough to warrant wider review. It is a true rewrite using quickbook; I generally used the implementation source code as the answer to my questions about things while writing the documentation. Early snapshots were reviewed by Tom Kent, Alexander Lamaison, Paul A. Bristow and Julian Gonggrijp. A special thanks to them for providing me with useful feedback and suggestions. The main thing that still remains to be added is a detailed explanation of the floating-point comparison algorithms used by BOOST_REQUIRE_CLOSE, BOOST_REQUIRE_CLOSE_FRACTION and BOOST_REQUIRE_SMALL. The corresponding examples also need to be updated. The existing online documentation has had all the math symbols stripped out of it, so it is pretty useless. I'm probably just going to typeset the formulas with LaTeX and then capture them as images that are included in the documentation. (See <https://svn.boost.org/trac/boost/ticket/9539>) I'm guessing that modular boost should allow me to clone libs/test, make all my changes there and then issue a pull request, but I'm not sure how far along things are with the git transition? -- "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>

14 48

Trac request states - suggestion
by Neil Groves 19 May '14

19 May '14

Dear Boost Developers, While working with Trac to maintain Boost.Range I find that I frequently have solved issues but they are not ready to be merged to master due to the release schedule. I haven’t noticed a way in Trac to denote that the issue is fixed and waiting to be merged. This means that I frequently look up tickets that I have forgotten I have fixed. It also means that I have a sub-optimal process for merging to master. I wondered if we might be able to squeeze in a “fixed in branch” field. It would help me considerably. Do other developers think this would help? Do you solve this in another, perhaps better way? I’m happy to lend development time to get this done if there is consensus and we can risk me having write access to Trac code! Thanks, Neil Groves

5 5