- Boost - lists.boost.org

Re: [boost] ASIO does not fully support Windows Runtime and a suggestion for providing support
by Moshe Rubin 16 Jan '15

16 Jan '15

>> I highly object to the tone of your response. Bringing up a matter on >> this mailing list related to a Boost library is not a command for anyone >> to do anything. By responding the way you have done you are discouraging >> people with issues from using Boost mailing lists to start a discussion >> about a particular library. > I apologise if I have offended anyone on the list, including you > Edward. My thanks to Edward for standing up for a relatively new poster to this mailing list. There was absolutely no malicious or similar intention in my post, and certainly no "commanding and impatient tone". My intention was to improve ASIO, which is an incredible technological achievement. Our needs for a ported Boost for WinRT, as the needs of many others, are immediate, so I used the methods known to me, including posting to this mailing list. If I had a nickel for every WinRT developer pining for a complete port of Boost for WinRT, I'd probably be a rich man <g>. > However, there is an etiquette when dealing with deficiencies in open > source libraries. You first raise the issue with the library's > maintainers before going onto public lists - and before I replied to > the OP, I checked the github ASIO issue tracker and the Boost issue > tracker and found no mention of the deficiencies. It may be the case > that the OP has spoken to Chris by private email, but his post did > not indicate that. I am willing to learn the ropes and thank you for pointing out the correct procedure. As a matter of fact, I used a two-pronged tactic just in case and sent the same email to Chris in parallel (see his response below). > Furthermore, Chris fairly bluntly stated in the > ASIO release notes which added WinRT support that that support would > be limited, and he went into some detail as to how and why. That > would strongly suggests that the maintainer is well aware of the > limitations, and has a strong idea of what should be done about them > (if anything). Moreover, if he has left out a particular support for > something, he may well have very good reasons for that, including the > cost benefit reason. Indeed, I had not checked the ASIO release notes, and now know that that is most important. Reading them now, I see that Chris limited his port. As a WinRT developer, I know why he decided to do so. > So, go raise it with the maintainer first, and that's probably best > done as I mentioned via the ASIO github issue tracker which Chris > definitely responds quickly to. If the maintainer refuses to support > what you need, *then* come onto this list to see if anyone else is > having the same problem, *then* see if you can put together a > coalition of the willing. However, to be honest, I think the > maintainer will be happy to improve WinRT support, you just need to > prearrange what form he'd prefer it to come in. Here is Chris's courteous reply to me: <quote> Thanks for your email. I was not aware that Windows Phone now supports Winsock. This is great news. However, I am a bit confused by your proposed design. I don't believe we need a new socket service at all. If Windows Phone now supports Winsock then we simply need to prevent BOOST_ASIO_WINDOWS_RUNTIME from being defined - see asio/detail/config.hpp. Then, provided that BOOST_ASIO_WINDOWS *is* defined and BOOST_ASIO_HAS_IOCP is *not*, it will use the existing select()-based reactive_socket_service backend. This backend is already supported on Windows, and was used in the past to support Windows 9x and WinCE. I suggest you start by modifying asio/detail/config.hpp to make those changes, and then see what errors happen after that. There will most likely be other changes needed to work around Windows API functions that are still unsupported on Windows Phone. Cheers, Chris </quote> > And BTW, after you've talked to Chris and gotten green lit by him, > absolutely do ping this list with what you've agreed to do and ask > for feedback on it. The people I'm currently contracting for would be > very interested in improved WinRT support in ASIO. I'm sure so would > others on the asio-users ML. And as ASIO is going to be the > Networking TS, I daresay so would Microsoft, indeed you might even > get some improvements to WinRT to help ASIO along - we have the main > Microsoft engineer who ported Boost to WinRT on this mailing list. So here I have a question: when I've followed up on Chris's suggestions and have ASIO working for ASIO, what should I do next? Return to the mailing list to announce the fact and ask for feed as you suggest, or schedule a GitHub pull request? I have recently been in contact with Steven Gates, who has been very helpful on my quest of porting Boost for WinRT. In conclusion, Niall, I thank you for educating me on the etiquette on Open Source public mailing lists. I trust you've also learned not to pull the trigger too quickly. Moshe

6 5

Regarding Contribution to Boost Library
by Siddharth Agrawal 16 Jan '15

16 Jan '15

Hello all, Myself Siddharth Agrawal, I have been using boost library since 1 year.Now I want to contribute to the development of this library. Can anyone guide me where should I start. I would be grateful for this. Moreover I also want to know the github page of Boost. Regards, Siddharth Agrawal.

3 3

Interest in a FIX Protocol Library?
by Marius Dobrea 16 Jan '15

16 Jan '15

Hello Boost, I have been following the boost email lists for a while now and would like to contribute to Boost too. Since it matches at best my experience it would be probably most beneficial if I contribute to a BOOST/FIX library. FIX comes from the "Financial Information eXchange" Protocol and it represents a standard that is used a lot in the Financial Industry. For more information see the related Web Site: http://www.fixtradingcommunity.org. Firstly I would like to ask the community if there is interest in such a library and if anyone is doing any work on it. It seems to me that although there are a lot of firms and institutions in the world providing software or using FIX there are too few open source C++ libraries for that. Secondly I would like to receive feedback on what functionality would be interesting to be part of this library. For instance it could contain: - basic components that can be used to build bigger blocks: e.g.: raw data iterators, message components, field types; - conversion functions from FIX to C++ types and vice versa; - code generators for Messages, Enums, Constants based on XML specification files; - implementations for various FIX Session types: Tag-Value, FAST, FIXP, user defined messages, etc; - transformers which based on some configuration could convert messages automatically between various FIX versions; - message persistence, etc. FIX is very well documented and as such various functionality could be probably easily split into interesting projects that are to be part of the GSoC. Let me know what you think. Thanks, Marius Dobrea

13 17

[sync] has no master branch?
by Peter Dimov 15 Jan '15

15 Jan '15

The module libs/sync has no master branch, why?

2 6

[timer] clang warning
by Peter Dimov 15 Jan '15

15 Jan '15

..\..\..\include/boost/timer/timer.hpp:44:43: warning: 'long long' is a C++11 extension [-Wc++11-long-long] void clear() { wall = user = system = 0LL; } ^ The fix in this case appears trivial, just remove the LL.

2 1

Unmerged changes in develop
by Peter Dimov 15 Jan '15

15 Jan '15

Many libraries have unmerged changes in their develop branches. Some of those are legitimate, many aren't. What follows is a list of the submodules for which git log master..develop reports something, created by git submodule foreach "git log -n 1 --oneline origin/master..origin/develop || :" and then edited slightly by me. Entering 'libs/accumulators' 2bf02f3 Merge pull request #2 from danieljames/metadata Entering 'libs/algorithm' d473435 Added more general power functionality as requested by Sean Parent. Also added enable_if to make sure the exponent is an integral type. Entering 'libs/array' 0d4fa27 Merge pull request #3 from boostorg/pull_request/remove_hash_fwd Entering 'libs/atomic' 427a757 Merge pull request #4 from jhunold/test_dependency Entering 'libs/bimap' dd4e612 Correct broken links to C++ standard papers. Refs #9212. Entering 'libs/chrono' d7478b9 move from math to integer for gcd(). Entering 'libs/concept_check' bb9257a Remove executable status from a bunch of source files Entering 'libs/config' 06aa40a Remove requirement that BOOST_MSVC_ENABLE_2014_JUN_CTP be defined to get the correct BOOST_NO_CXX11_* macros for VC++ 14.0 (aka 2015). Entering 'libs/container' 6932417 Support types with std::allocator_arg_at with boost::container::scoped_allocator_adaptor Entering 'libs/context' ac1b845 usei consistent use of BOOST_ASSERT Entering 'libs/conversion' 84ab592 Merge pull request #7 from Boris-Rasin/synopsis Entering 'libs/convert' f066fac turning std=c++11 on Entering 'libs/core' 2beeb73 Fixed a typo in the comment. Entering 'libs/coroutine' 9814084 remove feature segmented stack (already defined in boost.context) Entering 'libs/crc' 3de6617 Merge pull request #1 from danieljames/metadata Entering 'libs/date_time' ca30f6a Documentation patch from 'faithandbrave' Entering 'libs/detail' fcaf168 Initial commit if lightweight_test_report.hpp, aimed at making it easier for users to supply sample programs in bug reports. First use will be in filesystem. Entering 'libs/dynamic_bitset' 225064d Patch by Riccardo Marcangelo: Added a pop_back() member function which decreases the size of the bitset by one Entering 'libs/endian' 810f545 Work-in-progress, including various bug fixes and doc updates. Entering 'libs/exception' c1f6b74 Merge pull request #5 from danieljames/metadata Entering 'libs/filesystem' 96d5cdd Remove test_folder. Content is now in branch test-files/utf-8, so that master and develop conform to Boost file naming policy. Entering 'libs/foreach' 3bc8f66 Merge pull request #2 from danieljames/metadata Entering 'libs/format' 5826c68 Fix typo. Patch from kylelutz Entering 'libs/function' 157aaea Merge pull request #4 from apolukhin/rvalue_params Entering 'libs/function_types' caed0a6 Correct broken links to C++ standard papers. Refs #9212. Entering 'libs/functional' a478186 Fix version number in release notes. Entering 'libs/fusion' af1bc25 - disabling test for now (todo later) - removing irrelevant tuple test Entering 'libs/geometry' 9b6be5f [point] assign values differently such that: no warning is given, and explicit can be used for one constructor only Entering 'libs/gil' 1618df0 Merge pull request #12 from danieljames/metadata Entering 'libs/graph' 2573fbb Fix warning on const return by value. Entering 'libs/graph_parallel' 17214e8 Merge pull request #6 from michaelopitz/develop Entering 'libs/io' b3e349c Merge pull request #1 from danieljames/metadata Entering 'libs/iostreams' d702307 Correct broken links to C++ standard papers. Refs #9212. Entering 'libs/iterator' ec7d398 Merge pull request #10 from Flast/pr/ref-to-ref/dr106 Entering 'libs/lambda' 545b6af Merge pull request #1 from jzmaddock/patch-2 Entering 'libs/lockfree' 39cc67a lockfree: spsc_queue compile fix Entering 'libs/logic' b3adfec Merge pull request #2 from apolukhin/develop Entering 'libs/math' 9561623 [Beta/Gamma]Fix concept failures caused by previous commit. Entering 'libs/mpi' b4e8640 Enable new test now that missing source has been added. Entering 'libs/mpl' 6a0f617 Revert "Merge pull request #11 from Lastique/modularization" Entering 'libs/multi_array' 5578fc3 Merge pull request #6 from MarcelRaad/patch-1 Entering 'libs/numeric/conversion' c90517d Merge pull request #3 from danieljames/metadata Entering 'libs/numeric/interval' 538299d Apply https://github.com/boostorg/interval/pull/1 manually; qualify four calls to 'to_int' with 'this->' Entering 'libs/numeric/odeint' d69cba8 Merge pull request #5 from danieljames/metadata Entering 'libs/numeric/ublas' 12f6c6c Merge pull request #16 from danieljames/develop Entering 'libs/optional' a8a6be0 More tests migrated to core/minimal_test Entering 'libs/parameter' 54854d4 Correct broken links to C++ standard papers. Refs #9212. Entering 'libs/phoenix' e168b28 Updated preprocessed files Entering 'libs/predef' 84967e3 Add missing BOOST_PREDEF_MAKE_0X_VVRRPP macro (thanks ro Erik Lindahl for finding it). Entering 'libs/preprocessor' fd135a0 Added BOOST_PP_LIST_SIZE_D to list of re-entrant macros. Entering 'libs/program_options' 0c01e9a Add testing for implicit_values and non-consuming of separate tokens. Entering 'libs/property_map' ba0bed2 Merge pull request #2 from danieljames/metadata Entering 'libs/property_tree' 24125b4 Merge pull request #6 from danieljames/metadata Entering 'libs/proto' 8566061 get lambda example compiling on clang Entering 'libs/ptr_container' 9ed3379 Merge pull request #1 from BenPope/develop Entering 'libs/python' 6b7e0cc Remove all references to now defunct (and removed) header. Entering 'libs/random' a8aed49 Use the right upper bound for the exponent. Entering 'libs/range' 4f3bdbe Merge pull request #24 from steveire/remove-algorithm-dep Entering 'libs/ratio' 591a1e6 Merge pull request #2 from danieljames/fix-json Entering 'libs/regex' 39aa10d Fix for: https://github.com/boostorg/regex/pull/9 Entering 'libs/serialization' 594541b Merge pull request #4 from danieljames/metadata Entering 'libs/signals' 7dc7b47 Merge pull request #4 from danieljames/metadata Entering 'libs/smart_ptr' f65c57d Fix explicit instantiation regression Entering 'libs/spirit' f51566b Merge pull request #75 from mloskot/develop Entering 'libs/statechart' c9cf783 Merge pull request #1 from apolukhin/develop Entering 'libs/static_assert' bb3cc11 Merge pull request #2 from mgaunard/clang_warning_fix Entering 'libs/test' bf1c122 Now just "using" Entering 'libs/thread' 2c028aa fix more erros after Boost.Test commit. Entering 'libs/throw_exception' a9de81a Merge branch 'master' into develop Entering 'libs/timer' f4ec9cc Merge pull request #1 from danieljames/metadata Entering 'libs/tokenizer' 2fa9f44 Merge pull request #4 from Lastique/patch-1 Entering 'libs/tr1' 9f28b87 Merge pull request #2 from danieljames/metadata Entering 'libs/tti' 7b13a81 Merge pull request #1 from danieljames/metadata Entering 'libs/tuple' b54dd80 Merge pull request #6 from K-ballo/boostbook Entering 'libs/type_erasure' e92682a VC12's variadic templates have some bugs. Fall back on the PP implementation for some components. Entering 'libs/type_index' 8558fd6 remove the always failing testing_crossmodule_anonymous_no_rtti test from test suite and add notes for users about emulation limitations testing Entering 'libs/typeof' 4e34737 TypeOf: Fix if/elif chain after msvc 6/7 removal. Entering 'libs/unordered' 68eb654 Merge pull request #4 from tempoz/patch-2 Entering 'libs/uuid' d233193 Fixed compilation. Entering 'libs/variant' e00c75c Continue fixes, pointed out by Adam Wulkiewicz: removed unnecessary reference_content.hpp include, added missing static_assert.hpp include Entering 'libs/wave' bb0adbf Merge pull request #2 from danieljames/metadata Entering 'libs/xpressive' 7377713 Merge pull request #3 from danieljames/metadata Entering 'tools/build' f5b31b3 Block signals to end of exec_cmd. Entering 'tools/quickbook' b93c2a7 Use quickbook 1.7 for documentation.

3 6

[ratio] clang warning
by Peter Dimov 15 Jan '15

15 Jan '15

Ratio gives a warning under Clang: ..\..\..\include/boost/ratio/ratio_fwd.hpp:87:58: warning: 'long long' is a C++11 extension [-Wc++11-long-long] typedef ratio<BOOST_RATIO_INTMAX_C(1000000000000000000), BOOST_RATIO_INTMAX_C(1)> exa; ^ ..\..\..\include/boost/ratio/config.hpp:47:33: note: expanded from macro 'BOOST_RATIO_INTMAX_C' #define BOOST_RATIO_INTMAX_C(a) INTMAX_C(a) ^ ..\..\..\include/boost/cstdint.hpp:66:26: note: expanded from macro 'INTMAX_C' # define INTMAX_C(c) c##LL ^ I'm not sure how this can be avoided though.

2 2

Re: [boost] [compute]/ Futures Some remarks
by Antonio Colino 15 Jan '15

15 Jan '15

> > On 01/14/2015 10:46 PM, Antonio Colino wrote: > > I have a flawless implementation of this concept I am very proud of. Is any one willing to critique it? > > On 01/14/2015 10:46 PM,?Thomas Heller?wrote: > > Wanna share it? Which concept are you refering to? > > I was hoping to share this lib, if i could generate any interest in a copyable hpc version of packaged_task > On Jan 2015 20:36:40,?Thomas Heller?wrote: > Absolutely! Note that there are already a few out there doing exactly what > you described (HPX and Habanero++ come to my mind here). What would be the best way to arrange this?

1 0

Marking explicit failures -- need help
by Andrzej Krzemienski 15 Jan '15

15 Jan '15

Hi All, I would like to make some regression tests as expected to fail in explicit-failures-markup.xml, but I have the following problem. Not sure if this is specific to Optional tests: http://www.boost.org/development/tests/develop/developer/optional.html I have two "columns" with the same toolset label "gcc-4.4.7" from tester "Sandia". On one the test passes, on the other: it fails. This is because on one C++0x is enabled. But I cannot tell it from the toolset label alone, and therefore I cannot make the correct entry in failures-markup.xml: either I mark too much or too little. Does anyone know away around it? Can you mark failures based on something else than toolset name? Regards, Andrzej

1 1

Re: [boost] [compute]/ Futures Some remarks
by Antonio Colino 15 Jan '15

15 Jan '15

On 01/14/2015 10:46 PM, Antonio Colino wrote: > I have a flawless implementation of this concept I am very proud of. Is any one willing to critique it? On 01/14/2015 10:46 PM,?Thomas Heller?wrote: > Wanna share it? Which concept are you refering to? I was hoping to share this lib, if i could generate any interest in a copyable hpc version of packaged_task

2 1