- Boost - lists.preview.boost.org

[OFF] Inclusive language (Was: [review][beast] Review of Beast starts today : July 1 - July 10)
by Vinícius dos Santos Oliveira 21 Jul '17

21 Jul '17

2017-07-01 21:54 GMT+02:00 Vinnie Falco via Boost <boost(a)lists.boost.org>: > Such language is non-inclusive and diminishes the stature of the list > (in my opinion). So what? What's the problem of non inclusive languages? This is just automatic reaction. Rust language community is full of this shit and is unbearable. “but-but-but the feelings... oppression”. Grow up. If you're on the Rust community, you cannot criticize design decisions that anyone will answer with “you have a very negative tone indeed”. That community is cancer (oh... I just used an oppressive word... how unpleasant I'm looking now...). And it's the same community which will **applaud** a guy who says shit about async I/O... like... “I think the proper way to use async I/O is creating threads”. The same fucker who says “I don't like Windows... that's why I don't support Windows”. As a matter of fact, I don't like Windows either, but I leave my non-important programming tastes out of my working environment (so oppressive). Next time you will want to ban blacklist/whitelist from your repos because that's racist. Stop this fucking nonsensical bullshit. You end up hiding yourself behind a prepared excuse. The only part I agree with you is the part on keeping the topic focused. That's why I'm creating another topic just for that. Niall's comment was absolutely on topic as a critique of the obvious. He could just say in other words, like “you're not programming seriously if you ignore error handling”. Or he could be so desperately concerned about politically correct. It'd be a great and unnecessary distraction. He would start to censor himself and not say everything which may be of value because he is scary of “improper language”. He didn't even need to censor himself this time (you've done this for him — a community of self-vigilant sheep... how wonderful will be our future... just like Rust and its “nazi-demographic surveys/corrections-to-be-done”). Do not mirror Rust's bad practices here. Do as Niall and try to mirror the good parts instead (e.g. error handling). Feel free to only answer after review of Beast finishes. Otherwise I'll steal focus that shouldn't be stolen now. Actually, I suggest to only answer after the review period finishes. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 10

Strawman proposals for CMake support
by Louis Dionne 21 Jul '17

21 Jul '17

Hi, I'd like to expose two strawman proposals for adding CMake support to Boost. Both proposals would solve the following problems, with different advantages and disadvantages: (1) Users have a hard time integrating Boost into their build system, which is CMake more often than not. (2) Prospective Boost developers are sometimes driven away from submitting because they would have to learn Boost.Build, which is not widely used and has a limited knowledge base. FIRST PROPOSAL ============== The first proposal is to move completely to CMake and to render Boost.Build support optional. The possible rollout plan would look something like: 1. We start requiring that new libraries support both Boost.Build and CMake. 2. We start adding CMake support to existing libraries. This will take time. 2.1 We start moving our infrastructure to be CMake-based. 3. We release Boost with dual support for a while, letting time for things to bake. 4. We remove the requirement that Boot libraries can be built with B2. Libraries (existing and new ones) are free to provide such support, but they are not required to. This would bring CMake to the status of "primary" build system for Boost. This could be based on Paul Fultz's work in progress at [1]. This has the following advantages (in the long term): - Less technical debt because we only have one "official" build system to maintain. - The build system is uniform across all of Boost, which means it's easier for folks to maintain it and understand it. - It gives maximal flexibility to CMake-based users. However, it has the following drawbacks: - We'll need to do a wholesale migration to build system XYZ when CMake is not cool anymore. - It's harder to get buy-in from some developers that love Boost.Build SECOND PROPOSAL =============== The second proposal is to make Boost into an almost build-system agnostic collection of libraries. Basically, 1. Provide CMake package config files for all Boost libraries so that they can be used from CMake (either automatically, manually, or a mixture of both). This could be based on Peter Dimov's work at [2] (or [3], not sure which one is most current). 2. Make it possible to build CMake-based projects from Boost.Build, or the other way around, or provide a build system agnostic script to build all of Boost. This way, Boost libraries can decide whether they want to support B2 or CMake. This has the following advantages: - Possibly easier to implement - We could possibly support other build systems too (e.g. if a Boost author really wants to use scons for his/her library) - We don't have to do a wholesale move to XYZ when CMake is not cool anymore I see the following disadvantages: - Boost's infrastructure could grow more complex as a result - Our build system would be less uniform - We would have to depend on all the build systems that we want Boost libraries to be usable with My personal preference is towards the first option, since I think it would be simpler in the long term. I could certainly be convinced otherwise. There are probably other ways we can solve problems (1) and (2) exposed above. There are also certainly advantages and disadvantages that I forgot to mention above. I'd love to get some feedback on those two approaches and see whether one of them (or something else completely) can get some consensus on this list. Cheers, Louis [1]: https://github.com/boost-cmake/bcm [2]: https://github.com/pdimov/boost-cmake-demo-2 [3]: https://github.com/pdimov/boost-cmake-demo -- View this message in context: http://boost.2283326.n4.nabble.com/Strawman-proposals-for-CMake-support-tp4… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 9

A vision of Boost
by David Sankel 21 Jul '17

21 Jul '17

I got involved with Boost in 1999. I was 17, attempting to learn C++, and saw a footnote in "The C++ Standard Library" that mentioned boost.org as a place where quality C++ libraries are found. For me, it was love at first sight. Automatic pointers? Amazing. 'std::array'? Fantastic. I've been using C++ and Boost ever since. Never in my wildest dreams would I have imagined that eighteen years later I'd be sitting on the C++ standardization and Boost steering committees. As I listen in the Library Evolution Working Group I imagine what it must've been like for Beman and Dave to sit in similar meetings and ask themselves "wouldn't it be great if there were an online place that collects freely available C++ libraries and offers a peer-review process for incorporation? It'd be hugely beneficial for C++ users and the C++ standard as well." People get involved in Boost for many reasons. Some think it'll improve the chances they get their library standardized (and it's true!). Some think it'll improve their consulting or job prospects (true as well!). Others hone in on particular aspects, such as the build system, the people, or individual libraries. All these reasons are great, but for me the key was Boost's mission: to improve the way people code. At first it was more about improving the way I code, but as time went on it became more and more about helping others. For me, this is something worthwhile; worth sacrificing for. Now there are pros and cons with moving Boost to CMake, but at the center of all steering committee discussions has been the Boost mission. "How is this going to help us reach more users?" "How is this going to help us reach more developers?" "How is this going to impact the standard and the greater C++ community?" We may have made the wrong choice (though I doubt it). We may have communicated it in a non-ideal way. However, one thing is for sure: We made the decision based on furthering Boost's mission. A mission I want others to fall in love with like I have. So, we're moving to CMake. And, yes, we'll get there together. Many questions still exist and we'll have to figure out the answers as a community. The stalemate, however, is now over. -- David Sankel

2 1

[outcome v2] ntkernel_category() custom error category appropriate for Outcome?
by Niall Douglas 21 Jul '17

21 Jul '17

I put together a custom `std::error_category` for NT kernel `NTSTATUS` error codes with error condition comparison support for both POSIX and Win32 error code spaces: https://github.com/ned14/ntkernel-error-category Question: Is this custom `std::error_category` so niche and unlikely to be useful to anybody that people would object to it being supplied in Outcome v2? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

Greetings everyone!
by Arnav Karmarkar 21 Jul '17

21 Jul '17

Hello, I'm Arnav. I came across Boost when going through the list of organisations that take part in GSoC. I found Boost very interesting, so can anyone guide me with how to proceed? Thanks!

2 1

[BB++] Now is 3.5x faster than Node.JS
by Phil Bouchard 21 Jul '17

21 Jul '17

Greetings, I am now using C++14 standards, the error reporting is all compile-time now and I get a test that is 3.5 faster than Node.JS! You can see it by yourselves here: https://github.com/philippeb8/root_ptr/tree/bb++/bbpp2cpp Furthermore there is no need for 'operator ->' anymore because the access operator is deduced at compile-time. Here is a code sample: int main() { int temporary = 1; auto foo = function () { return function (int argument) { return argument; }; }; for (int i = 0; i < 1000000; ++ i) cout << foo()(temporary) << endl; } Note that it's also possible to dynamically allocate function pointers like this: int main() { int temporary = 1; auto foo = new function () { return new function (int argument) { return argument; }; }; for (int i = 0; i < 1000000; ++ i) cout << foo()(temporary) << endl; } I will show you a clear example of cyclic references handling soon. Regards, -Phil http://bbplusplus.com/

1 0

boost no longer builds mpi libraries when using intel mpi
by Franck Houssen 20 Jul '17

20 Jul '17

Hello, Just to get your attention to this : https://github.com/easybuilders/easybuild-easyconfigs/issues/1065 Franck

4 13

MS controlled email domains - not going to work
by Michael Caisse 20 Jul '17

20 Jul '17

The irony in sending this message is that the people who need to see it probably wont get it. We are having trouble with hotmail.com, live.com, msn.com, and outlook.com. Microsoft is filtering the dedicated IP address used by the mail lists and most recently has responded with: Not qualified for mitigation [ip address] Our investigation has determined that the above IP(s) do not qualify for mitigation. These IP(s) have previously received mitigations from deliverability support, and have failed to maintain patterns within our guidelines, so they are ineligible for additional mitigation at this time. We have tried to explain multiple times that the IP address has a new owner but we seem to be stuck in almost an auto-response loop. We will continue to try and get service unblocked; however, I would recommend that you dump your MS controlled accounts for Boost mail lists and use another service. michael -- Michael Caisse Ciere Consulting ciere.com

2 1

Re: [boost] CMake announcement timing
by Bjorn Reese 19 Jul '17

19 Jul '17

On 07/19/2017 06:03 PM, Edward Diener via Boost wrote: > I think it is very unfair to make the announcement regarding Boost and > CMake while a review is ongoing. Surely the announcement could have > waited until after the review period for mp11. I raised this point with Jon yesterday in my role as review manager. The situation is difficult to handle now that the announcement has been made, other than to ask people to show temperance for the duration of the review, which ends next Monday (July 24th.)

1 0

CMake announcement timing
by Edward Diener 19 Jul '17

19 Jul '17

I think it is very unfair to make the announcement regarding Boost and CMake while a review is ongoing. Surely the announcement could have waited until after the review period for mp11.

3 2