- Boost - lists.boost.org

qxcalc(GSoC2019)
by Ggh 07 Feb '19

07 Feb '19

Hi all, Not sure if there is interest, but some years ago I coded a parser/lexer with flex and yacc to do math. The project is online here "http://qxcalc.sourceforge.net/" Greg

1 0

GSoC 2019
by David Bellot 07 Feb '19

07 Feb '19

Hi Boost community, this year again we applied to the GSoC programm, Google Summer of Code. We hope to be as successfull as usual. I'm taking care of the admin work again this year. I completed an application for Boost on the Google website. It is somehow similar to our successfull applications from previous years. What we need from the community now is the following: 1) if you want to be a backup admin (I will need maybe one or two extra names at most), please let me know and I'll send you an invite. 2) if you wish to be a mentor, please let us know now and if possible on this mailing list so that students will be aware of it too. Don't forget to put the [gsoc2019] tag in the header of your email. You can write your proposals on this wiki: https://github.com/boostorg/boost/wiki/Google-Summer-of-Code:-2019 Ideally, we want to see many proposals before beginning of next week. 3) if you are a student and wants to participate, it's about time to speak loudly on the mailing list to pair with a potential mentor. The sooner the better. You can find ideas from previous years here: https://github.com/boostorg/boost/wiki/Google-Summer-of-Code%3A-Overview Happy coding. David

7 7

find_package(Boost) support
by Peter Dimov 04 Feb '19

04 Feb '19

The current master and develop branches now install the necessary BoostConfig.cmake file (in $prefix/lib/cmake) such that f.ex. the CMake command find_package(Boost REQUIRED filesystem) will find Boost 1.70 using the config file, rather than via FindBoost.cmake (*) (if the Boost installation prefix is in CMake's prefix search path.) Interested parties are invited to test this support and share their experiences. Instead of a Git checkout, you can use the 1.70 release snapshots from https://dl.bintray.com/boostorg/master/ or https://dl.bintray.com/boostorg/develop/, as those better represent what the 1.70 release will contain. (*) Actually, the above command will invoke FindBoost.cmake, but FindBoost will look for a config file as a first step and use that, if found. To disable FindBoost completely, use find_package(Boost CONFIG REQUIRED filesystem) Or, on Windows, assuming the default C:\Boost installation, find_package(Boost REQUIRED filesystem PATHS C:/Boost)

4 4

Coordinating Parameter 'master' merging for dependent libraries
by Edward Diener 03 Feb '19

03 Feb '19

I intend to merge Parameter 'develop' to 'master' for the next release of Boost. Cromwell Enage has done a great job of adding modern improvements to the Parameter library via PRs, while maintaining full backward compatibility with the Parameter public interface. I have reviewed and approved those changes and, where I have been lax, Peter Dimov has pointed out weaknesses in some of those changes, which Cromwell has corrected. The changes which Cromwell has made have also involved improvements in the Parameter private interface(s), which have entailed some updates to the 'develop' branch of some Boost libraries which unfortunately depended on some aspects of the Parameter private interface. These updates have already been made in those other library's 'develop' branch. At this point any further possible changes for Parameter for a while will very likely be in the Parameter documentation, which requires no syncing with other libraries, so this is an excellent time for merging. Since the merging for other libraries dependent on Parameter must be synced to the merging of Parameter from 'develop' to 'master' what is the best way to go about this ? Obviously I have first to merge Cromwell's changes from 'develop' to 'master', which is easily done. How should I inform other libraries that they need to merge their Parameter dependent 'develop' changes to 'master' ? Should I create PRs for doing this ? We do not normally create PRs for the 'master' branch of any Boost library. Should I create Issues for those other libraries and hope the maintainers of the other libraries will take the appropriate action ? Or should I inform the maintainers of the other libraries in this thread, and prompt them to review their changes here to get them to merge them from 'develop' to 'master' ? The other libraries involved are: Accumulators, Log, Convert, Lockfree, Signals2, and Graph. Cromwell knows more about the specific 'develop' changes in those libraries which need to be merged to 'master' than I do, since he was instrumental in creating the PRs that would allow these libraries to work with the updated Parameters' internals, so he may chime in here, but I would like to get this done so that Parameter and its dependent Boost libraries get properly updated for the next Boost release. Of course I will also plan with Cromwell update notes for Parameter to be part of the next release.

3 2

[GSoC19] run-time Ratios
by Fenil Mehta 03 Feb '19

03 Feb '19

Hi everyone, It has been noticed that C++ provides a class to store ratios/fractions at compile-time. They provide very limited functionalities and are not modifiable during run-time. My *idea* is to have a *Ratio class* which provides all the necessary functionalities at run-time as well. I have already implemented this partially and I am willing to make it 100% ready for inclusion in Boost. Some guidance would be appreciated on how to proceed with this idea for GSoC19. Would anybody be interested in mentoring this idea for GSoC19 ? Regards, Fenil Mehta

2 1

[interprocess] 32-bit offset_ptr
by Phil Endecott 03 Feb '19

03 Feb '19

Dear Experts, I have some old code that uses 32-bit offset_ptrs, i.e. typedef boost::interprocess::offset_ptr<void, int32_t, int32_t> ptr_t; This has stopped working on 64-bit systems at some point since 1.58. git blame suggests a commit on 14 Oct 2015. There is now a static assert that checks that OffsetType is at least as large as a raw pointer. In the current case, I'm using these pointers within memory-mapped files which will always be vastly smaller than the 32-bit limit. Using 32-bit offsets seemed like a worthwhile optimisation at the time, and now I am hoping to maintain binary compatibility with those files. In the past I've also used them to save memory on 64-bit systems with pointer-heavy data structures (using boost.intrusive) using an allocator that operates within a small memory region. Has something changed within the implementation that makes this restriction necessary? Was it never supposed to work as I was using it? There is also an assert that OffsetType is unsigned, which wasn't there before. Maybe I was doing that wrong. Thanks for any advice. Regards, Phil.

3 3

[GSOC 19] Boost.ublas project Idea
by Amit Singh 02 Feb '19

02 Feb '19

Hi, My name is Amit Singh and I’m a 2nd year student. 1. I have studied last years ublas stats project and before that ublas lacked any statistics features, I would like to take boost.ublas stats further with 1. Linear Regression 2. Logistic Regression 3. Rigid Regression 4. Kernels ( Exponential Kernel, Gaussian Kernel, etc) 5. Correlation (Pearson product-moment correlation, Linear correlation, etc) 2. In ublas there is no expression solver which can solve a expression and assign the value to variable for ex:- A. matrix<double> m = “A^2 * (B * A^-1) + (det(A) * I)”; B. matrix<double> m = “A + 3” ; =>[ m = A + 3*I ] 3. In ublas to modify matrix you have to iterate using for loop. I’m hoping to create a function similar to transform in c++ or map in javascript 1. This is my small machine learning library that I implemented in c++ https://github.com/amitsingh19975/ML Would anybody be interested in mentoring my project for gsoc 19? or help me to improve my project ideas.

1 0

[thread] Passing function with parameters to boost::barrier
by André Offringa 01 Feb '19

01 Feb '19

Hi Boost developers, I'm having a problem with passing a completion function to a boost::barrier, causing a segfault, and I suspect it is a bug in the barrier code. The following is a minimal example that shows the problem: #include <boost/thread/barrier.hpp> void func(int) { } int main() { boost::barrier b(1, std::bind(func, 42)); b.wait(); } Running inside gdb and doing a bt shows some infinite recursion happening, starting with: #0 0x000055555555e41a in boost::thread_detail::decay_copy<boost::detail::nullary_function<void ()>&>(boost::detail::nullary_function<void ()>&) ( t=<error reading variable: Cannot access memory at address 0x7fffff7feff0>) at /usr/include/boost/thread/detail/move.hpp:355 #1 0x000055555555d814 in boost::detail::nullary_function<void ()>::nullary_function<boost::detail::nullary_function<void ()>&>(boost::detail::nullary_function<void ()>&) ( this=0x7fffff7ff0c0, f=...) at /usr/include/boost/thread/detail/nullary_function.hpp:81 ... When I change "std::bind(func, 42)" to just "func" (and declare func without parameters), it does work and the program exits normally. Passing a lambda to barrier (e.g. barrier(1, [&]() { func(0); } ) ) causes the same segfault, and the same holds when I change std::bind to boost::bind. I'm using Boost 1.67 on Debian Linux, amd64, gcc 8.2.0. Is this a bug? Cheers, André

2 1

[asio]https significantly reduce performance
by lx 31 Jan '19

31 Jan '19

Hi Boost experts: I build a https server from asio example of server2, let it support ssl.we use the codes from: *https://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/example/http/server2/main.cpp <https://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/example/http/serv…>* *https://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio/example/ssl/server.cpp <https://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio/example/ssl/serve…>* I complie the codes with boost_1_64 and openssl-1.1.0j, the commed line of complie is: *g++ -g -Wall -o https_server2 *.cpp -I/usr/local/include/ -I/usr/local/openssl-1.1.0j/include -L/usr/local/openssl-1.1.0j/lib -I/usr/local/boost_1_64_0/include /usr/local/boost_1_64_0/lib/libboost_thread.a /usr/local/boost_1_64_0/lib/libboost_system.a -Wl,-Bstatic -lglog -lunwind -Wl,-Bdynamic -lpthread -lcrypto -lssl -ldl -lrt* I test the https_server2 by ngrinder, the TPS is just 400, If I test is just http request , the TPS is 36000. So https significantly reduce performance. The perf top result is: [image: 1.png] The top result is: [image: 2.png] When I test it by http request, the top result is: [image: 4.png] I have push the codes on github. https://github.com/lxlenovostar/Programming_language/tree/master/cpp/test/s… I test 2, 4, 8, 24, 32 threads,but this can't improve the TPS.I test the nginx with 32 worker process, The TPS is about 5000. So maybe lock in asio ? btw: cpu is 32 cores, and Intel(R) Xeon(R) CPU E5-2440 v2 @ 1.90GHz memory is 66GB. os is CentOS 6.5 kernel is 2.6.32 Thank you.

5 6

[gsoc19][astronomy]
by Pranam Lashkari 30 Jan '19

30 Jan '19

Hello everyone, Last year I worked on the new astronomy library[0] and successfully completed GSoC with the help of my mentor *Vinícius dos Santos Oliveira*. In last GSoC, I completed basic coordinate systems and FITS file reading. *Current State of the Library:* Currently, this library has 7 basic astronomical coordinate systems implemented (Alt-Az, CIRS, ICRS, Galactic, Geocentric, Heliocentric, Supergalactic) which as actually wrappers around Boost::Geometry. IO module provides support for FITS reading. Right now, It can read primary HDU and image extensions. Development during GSoC can be found on the master branch[1] To preserve all the development done during the period of GSoC a separate branch was created after completion of GSoC named "gsoc18"[2]. All the development done after the period of GSoC can be found on develop branch[3]. No changes were merged to master after GSoC 18. *Idea for Boost GSoC19:* After communicating with the Boost::geometry community, integration of Boost::geometry and Boost::units is not supported and without using units scientific calculations are not error proof. As a result current coordinate systems can not be used with large projects as there are high possibilities of error. So this year I would like to implement Boost::unit with Boost::astronomy::coordinate to provide a robust astronomical coordinate system. Apart form this I would also complete the remaining parser for the FITS to read complete file including all types of extensions. I am targeting to complete the first coordinate system and FITS reader at the end of this GSoC and making this library ready for its first release. [0]: https://summerofcode.withgoogle.com/projects/5503102778605568 [1]: https://github.com/BoostGSoC18/astronomy/tree/master [2]: https://github.com/BoostGSoC18/astronomy/tree/gsoc18 [3]: https://github.com/BoostGSoC18/astronomy/tree/develop Thank you, Pranam Lashkari

2 2