- Boost - lists.preview.boost.org

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

Re: [boost] [algorithm] Review Request: edit_distance
by Ahmed Charles 19 May '14

19 May '14

Marshall will probably be busy for the next few weeks. Have you asked Ron about review manager approval? ________________________________ From: Erik Erlandson Sent: 4/14/2014 7:20 PM To: boost(a)lists.boost.org Subject: Re: [boost] [algorithm] Review Request: edit_distance ----- Original Message ----- > > > > - Have you looked at the supposedly better algorithm "An O(NP) > > > > Sequence Comparison Algorithm" by Sun Wu, Udi Manber, and Gene > > > > Myers ? > > > > > I've been doing more cross-testing and benchmarking against the current > > O(ND) > > version. The latest O(NP) prototype is passing randomized cross-testing > > and is now about 25% faster than the O(ND) baseline. My latest prototype code based on O(NP) is now running about 35% faster than O(ND) in my benchmarking: https://github.com/erikerlandson/algorithm/blob/order_np_alg/include/boost/… > > I wrote up a blog post that describes the various ideas I applied to get this > result: > > http://erikerlandson.github.io/blog/2014/02/20/a-bi-directional-variation-o… _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

think-cell is using boost
by Volker Schöch 19 May '14

19 May '14

Hi, We would like to be listed in the Shrink Wrapped Boost section on the boost.org website: http://www.boost.org/users/uses_shrink.html · The name of the Application/Product/Service. think-cell · The name of the company (where appropriate). think-cell · A paragraph describing the Application/Product/Service. think-cell was founded in 2002 in Berlin and is today the leading vendor of productivity software for professional PowerPoint users. Its product suite covers the complete process of presentation creation - from analysis and preparation of business data to the graphical rendering of qualitative and quantitative results. Most international business consulting firms, as well as a large number of the well-known industrial global leaders, are among think-cell's customers. · Any information you can provide about which parts of Boost you used, along with any comments you may have on how Boost helped your product development. C++ is a great and versatile programming language, but only with boost it is a powerful development tool that facilitates really efficient programming. Our code is beautiful, concise and easily maintainable thanks to the following boost libraries: Algorithm, Assign, Config, Conversion, CRC, Date Time, Format, Fusion, Geometry, Integer, Interprocess, Intrusive, Iostreams, Iterator, Math Common Factor, Math/Special Functions, MPL, Multi-Array, Multi-Index, Numeric Conversion, Operators, Optional, Phoenix, Preprocessor, Proto, Range, Smart Ptr, Spirit, String Algo, Swap, Tribool, Tuple, Variant If you are looking for more information on what development problems we are facing every day go to our C++ Developer job posting<http://www.think-cell.com/career/jobs/development.shtml>. · URLs to your company's home page, and the home page of the Application/Product/Service if there is one. http://www.think-cell.com/ Thanks! Volker -- Volker Schöch | vschoech(a)think-cell.com<mailto:vschoech@think-cell.com> Senior Software Engineer We are looking for C++ Developers: http://www.think-cell.com/career ________________________________ think-cell Software GmbH http://www.think-cell.com<http://www.think-cell.com/> Chausseestr. 8/E phone / fax +49 30 666473-10 / -19 10115 Berlin, Germany US phone / fax +1 800 891 8091 / +1 212 504 3039 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schödl

1 0

Crisis, What Crisis ?
by Francisco José Tapia 18 May '14

18 May '14

When , in previous days, I had read messages about the dead of Boost, I stopped to think about it. I think Boost is not dead, even , it have an excellent health, but have problems related with the growth , in the same way than when a young, pass to be adult. Many things must be done in a different way. Every day I see new developers proposing new ideas. If one day, you don't see new ideas and new developers you can certificate the death of Boost. The value of Boost compared with other libraries is that the code is tested, and a company trust in Boost and use their libraries in their internal process and applications, this is not true with many others libraries. I think we must separate the interest of the Boost users and the Boost developers. The developers, usually, are people with great level of knowledge and experience , and the users usually don't have that level. Due this , many times times, the interest of the developers and the users don't agree. Many of the new libraries proposed, in absence of a detailed explanation, are incomprehensible by the majority of the users. If you don't improve the design of the opponent, copy it. Perhaps we must learn about others web as stack overflow , and extract ideas for our web system. I think we must extend the mechanism used for the errors, to the consults of the users. Must be easy and don't need to inscribe. The actual mechanism of the list , I think is appropriate for the developers. Many of the Boost libraries are included in the C++ standards, this show the quality of the library. But I don't think that the people use a boost library, being included in the standard and provided by the compiler. I think we must design an ordered close of that libraries, and locate in a part for to provide utility to the users of old compilers. This reduce the number of libraries and help to improve the clarity and simplicity of the library. Boost had become a very big structure, and perhaps , the actual procedures for to take decisions are not appropriate, in the same way that there are people with a great knowledge and experience and other just arrived, and their opinions can have the same value. I think it is a good idea to create an executive board, elected between the Boost members, in order to take the important decisions. One of the first decisions is what to do with the libraries pending of revision, and the acceptance of new libraries without reviewer. As commented before, we can have libraries very interesting for the developers, and uninteresting for the users, and the opposite. My library COUNTERTREE,( parallel algorithms over Red-Black trees, with random access iterators) is waiting since near two years ago. It's something new, don't exist nothing similar. I had showed to companies (Intel , Google, Valve ...), universities (Stanford, Texas A&M, Carlos III , Stony Brook...) and people of the C++ environment ( Scott Meyers, P.J.Plauger , ) , with a great acceptation. But in their home, Boost, is waiting since near two years, and a good idea stopped is a dead idea. I would like to know if it is interesting in Boost, in order to continue with the development ( there are many algorithms and functionality for to do ), or if it is not interesting, spend my time in others questions, leaving frozen the code. These are only my opinions, open to discuss and new ideas. I am sorry , because the English is not my native language, and it's hard for me to express the details of my ideas. Anyway, I offer my work and my collaboration, for to improve OUR Library. If I can be useful, please, say me and I will try. Yours Francisco Tapia fjtapia(a)gmail.com You can find the code and the documentation in my web pages in dropbox https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/index.html or if you prefer in a git format https://github.com/fjtapia/countertree_2.0

1 0

Re: [boost] [Boost-users] Stability of serialization across boost versions
by Brian Wood 18 May '14

18 May '14

Sohail Somani > On 18/05/2014 4:34 AM, John Maddock wrote: >>> Any feedback or suggestions other than not using boost for serialization? >> >> It was my understanding that stuff like that should be supported, if you >> have a test case then filing a bug report would seem to be in order? > > Based on the error, it seems like what is happening is that a newer > version of Boost is attempting to communicate with an older version of > Boost. The actual exception is from the archive itself, IIUC. The > library has explicitly said this is not supported, unfortunately. > > To the OP, I'd suggest not upgrading Boost serialization or requiring > upgrading in lockstep. Upgrading multiple hosts in random order means > new communicating with old. This is an unsupported use case. I have a serialization option. It isn't a Boost library, but it has support for some Boost types and we're willing to add support for other Boost types. -- Brian Ebenezer Enterprises - "He who *refreshes* *others* will *himself* be refreshed." Proverbs 11:25 http://webEbenezer.net

1 0

Re: [boost] Community Maintenance Team and neglected libraries
by Ahmed Charles 18 May '14

18 May '14

I'll be sure to take a look at the outdated pull requests when you send them to the cmt list. ________________________________ From: Beman Dawes Sent: 5/15/2014 3:35 PM To: Boost Developers List Subject: Re: [boost] Community Maintenance Team and neglected libraries On Tue, Apr 22, 2014 at 11:36 AM, Daniela Engert <dani(a)ngrt.de> wrote: > Am 22.04.2014 18:29 schrieb Ben Pope: > > There are quite a few places where the library code is probably fine, > > but the failure is in the test itself, the fix is often simple and > > uncontroversial. > > ... > > The responses have been frustrating to say the least, we really need a > > way to move forward on this. > > > You're so true with your observation. I'm a bit disappointed too. > > I'm sitting on a pile of simple patches to cleanup the existing tests > such that I don't have to wade through a morass of level-4 msvc compiler > warnings when running the test suite. This requires both fixes to some > of the libraries themselves (thereby finding real bugs on the way) and > fixes to the test code to get the tests compiled in the first place. > It's those sanitized libraries that I supply to my colleagues for > production code because it's our policy to be absolutely clean on > level-4 warnings. Some months ago, I've prepared some of those patches > (more yet to come) for inclusion into boost mainline, and some of them > were picked up. The rest of my pull requests seems to be neglected. I > prefer to refrain from spamming the mailing lists with reminders, but is > there a better way to get the message through? Dealing with > quality-of-implementation issues and acting like a janitor might not be > the most sexy job in the universe, but I'm happy to do it (rather than > just sitting on the fence) as long as it has an effect, eventually. > This is one of the specific examples we have been discussing at C++Now in Aspen this week. * You did the right thing when you submitted pull requests. * Your should get some form of response within a reasonable period of time. It will take the CMT awhile to put a specific time on "reasonable" but certainly a month with no response is not reasonable. * Please post a message on the CMT mailing list, with links to the pull requests that you haven't heard anything about. It is their responsibility to decide how to proceed. * If you have questions about global maintenance changes touching many libraries, the CMT list is the best place to ask for guidance. The CMT folks care about maintenance so it is not spamming the list to ask them maintenance related questions. HTH, --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Boost iterators are not SFINAE-friendly
by pfultz2 17 May '14

17 May '14

Boost iterators aren't SFINAE-friendly. This is a problem when building traits that detect certain behavior. Heres a simple example: #include <vector> #include <type_traits> #include <boost/iterator/filter_iterator.hpp> template<class> struct holder { typedef void type; }; template<class Iterator, class=void> struct is_advanceable : std::false_type {}; template<class Iterator> struct is_advanceable<Iterator, typename holder< decltype(std::declval<Iterator>() += std::declval<int>()) >::type> : std::true_type {}; static_assert(is_advanceable<std::vector<int>::iterator>::value, "This will pass"); struct predicate { template<class T> bool operator()(T&&) const; }; static_assert(not is_advanceable<boost::filter_iterator<predicate, std::vector<int>::iterator>>::value, "This won't pass"); Although, it doesn't always lead to a compile error(rather than subtitution failure), it does lead some very erroneous errors. Thanks, Paul -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-iterators-are-not-SFINAE-friendly-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[utility] Moving addressof out of Boost.Utility
by Glen Fernandes 17 May '14

17 May '14

I was informed the eventual plan is to get rid of Utility as a sub-module, and I observed that Assert was moved out already. If there's any interest in (and no objection to) moving boost::addressof out of it, I don't mind making that change. What would be the most appropriate home for it? A Boost.AddressOf sub-module similar to Boost.Assert? Glen

4 6