February 2018 - Boost - lists.preview.boost.org

Re: [boost] New Astronomy Library
by Pranam Lashkari 22 Feb '18

22 Feb '18

These days I was studying already available astronomy libraries in different languages. I found that "Astropy"( http://www.astropy.org/ ) is well established and it is being used in many places. Maybe one of the reasons for its success is that it is for Python. As we all know that python is one of the easiest languages to learn. Not all scientists are programmers and maybe that's why they find python and Astropy easy to use. So what I was thinking is, what if we build a similar structure to the same library? It will make things easier for those scientists who do not have much time to learn a new programming language and this will make the transition easier from python to C++. Is it a good idea? Pranam Lashkari On Mon, Feb 12, 2018 at 7:31 PM, JC Passy <jcpassy(a)gmail.com> wrote: > Dear Pranam, > > Sorry for taking so long to get back to you. > So I talked to some of my former colleagues about potential projects > related to the analysis of astronomical data. They forwarded me the > following paper which gives an example of the amount of data they are > dealing with and some solutions they have found. I think you might find it > interesting: > http://adsabs.harvard.edu/abs/2017PASA...34...38V > > I must say in terms of concrete ideas, they did not have anything specific > to suggest. Most of these large surveys have already teams dedicated to > develop a pipeline to deal with their specific data. However, we will keep > looking and talking to people, may be something will come up in the future. > > In the meantime, you seem to already have ideas for amateur astronomers. I > suggest you start with it (I am happy to help you if you feel like it) and > I will let you know if a potential project for professionals comes up. Does > it sound good to you? > > Cheers, > > Jean-Claude > > > On 26. Jan 2018, at 12:17, JC Passy <jcpassy(a)gmail.com> wrote: > > Dear Pranam, > > Sure, I am waiting for some feedback from two former colleagues of mine on > that matter. I should get something by early next week, I will let you know > as soon as I do. > > Cheers, > > Jean-Claude > > On 25. Jan 2018, at 13:49, Pranam Lashkari <plashkari628(a)gmail.com> wrote: > > Dear Jean-Claude; > > As you mentioned in your emails, you are having some ideas what can be > implemented in this library as per requirement of professionals in this > field. > Can you start discussing those ideas so that we can get a better idea of > how to structure this library? > > On Mon, Jan 22, 2018 at 1:40 AM, JC Passy <jcpassy(a)gmail.com> wrote: > >> Dear Pranam, dear Vinicius, >> >> not sure that my initial email made it to the mailing list. If it did, >> sorry for repeating myself. >> I am working as a computer scientist at the MPI for Intelligent Systems >> in Tübingen. Before that, I did my PhD in astrophysics and a postdoc. In >> general, I am also interested in using boost and developing a library that >> could be used by astronomers and astrophysicists. >> >> Looking at your proposal, I would second Vinicius’ opinion in the sense >> that one should try to make it a bit more specific. In particular, you >> should emphasize the *why* (what do you wish to accomplish? why would >> someone need/use it?) and the *who* (who is your target audience?). >> Regarding the latter, I see two options: >> >> 1) *amateur astronomers*: I personally do not know what their needs are, >> but I could try to find out. There are some open source projects dedicated >> to amateur astronomers (for instance https://openphdguiding.org to which >> we contributed), so that could be an option; >> >> 2) *professional astronomers*: I think a lot can be done, in particular >> regarding observational data analysis. They used *REALLY* old tools >> (IDL, IRAF, …) and given the future and upcoming surveys that will produce >> very large amount of data, they might have serious performance issues. This >> is why I believe they might benefit from using cutting-edge C++ libraries. >> >> I would be quite interested in option 2, and it could impact potentially >> a large audience IMHO. Of course, the “selling” part won’t be easy (people, >> especially astrophysicists :) won’t give up their old methods easily even >> though the new method is 10x faster) but we can facilitate this process by >> pin-pointing features that they really need. I will try to talk to some of >> my former colleagues this week and see what they think about that. In this >> case, this is a project that would need a bit of time to be properly >> defined and the deadline for GSoC18 is coming too soon. As far as I am >> concerned, this is no problem as this project does not need to be tied to >> it. >> >> Cheers, >> >> Jean-Claude >> >> >> On 21. Jan 2018, at 15:00, Vinícius dos Santos Oliveira via Boost < >> boost(a)lists.boost.org> wrote: >> >> 2018-01-21 8:07 GMT-03:00 Pranam Lashkari <plashkari628(a)gmail.com>: >> >> I have made this proposal for this new library(check attachment) >> Suggestions are invited. >> >> >> You need to focus more on "selling your project". Why is it important to >> have such library in C++ specifically? Isn't this one of those projects >> where other languages will do just fine? What market are we missing by not >> having this library? What C++ have to offer to make such library be >> inviting to write in C++? >> >> You mention "gather information from observation data". Does this mean >> you'll include a parser for some format? >> >> Can you compare this library with some non-C++ library and detail a little >> how will scope between the two differ (e.g. your library will focus >> initially only on X given the library is only starting)? >> >> For now, this should be good. When it's time to submit the student form >> through the GSoC platform, you'll also focus on selling yourself. I'll >> give >> more feedback on this when the time comes. Don't worry. >> >> Should I publish this on the wiki page of Boost GSoC 2018? >> >> >> >> Yes, please. You can put my name as a potential mentor. >> >> -- >> Vinícius dos Santos Oliveira >> https://vinipsmaker.github.io/ >> >> _______________________________________________ >> Unsubscribe & other changes: http://lists.boost.org/mailman >> /listinfo.cgi/boost >> >> >> > > >

3 4

[gsoc18] SafeFloat or Real
by Thomas Ferrand 21 Feb '18

21 Feb '18

Hello everyone, I'm a student willing to be part of this year GSoC program and I'd love to work with Boost. Among the proposed projects, I'm interested in two of them, Boost.SafeFloat and Boost.Real. As Damian Vicino is said to be the potential mentor of both, I already send him an email but don't have any answer for now. I've already made the competency test for Boost.SafeFloat but I don't know what to do now, wait for an answer? Seek another mentor? Can you please guide me? Thanks, Thomas Ferrand

2 1

new to the organization
by Rajat Miglani 21 Feb '18

21 Feb '18

Dear boost community, I am a GSOC aspirant and I'd like to contribute to your organization. I have read the project ideas and is interested in working on:- 1)Boost.SafeFloat or 2)Enhancing Boost.Intrusive Library Can I get some more info about how to work on these projects and the basic requirements so that I can learn them and be able to contribute to my fullest. Thank you,

2 1

Legal problem with Stackoverflow contribution under the "Creative Commons Attribution Share Alike 3.0" license
by Dominique CHABAUD 21 Feb '18

21 Feb '18

Hi all, In Boost 1.62.0 we saw in the following header file : boost/thread/win32/thread_primitives.hpp that the function inline ticks_type __stdcall GetTickCount64emulation() is a contribution coming from https://stackoverflow.com /questions/8211820/userland-interrupt-timer-access-such- as-via-kequeryinterrupttime-or-similar Stackoverflow re-lisensing to MIT is told to be in place starting Feb 1, 2016 and only for new contributions. But the StackOverflow contribution that has been borrowed in Boost is Nov 23, 2011 and contributions prior to Feb1, 2016 are under the "Creative Commons Attribution Share Alike 3.0" license which is not permissive. This causes legal problem. Hope somebody can fix this. Thanks Dominique

15 37

Re: [boost] C++03 / C++11 compatibility question for compiled libraries
by Glen Fernandes 21 Feb '18

21 Feb '18

Olaf van der Spek wrote: > > Glen Fernandes wrote: >> Before I became a contributor to Boost, and before I became a Boost >> library author, I was a user of Boost at Microsoft. Even as late as >> 2014 when I left the company, those projects depended on Boost for >> C++03 support. (In fact, at least one of the projects only dropped >> C++03 support as late as 2016). > > Where did the C++03 support requirement come from though, an old compiler? > Even VS 2010 knows some C++11 stuff. Supporting teams that were still on older compilers was the motivation, yes. Boost was upgraded more frequently than upgrading to a newer compiler (even though in this particular case, the compiler was developed within the same company). For that project I referenced which dropped C++03 support in 2016, they also dropped VC10 support in the same year. Those projects came to depend on the reliability of Boost for its implementation of standard library facilities that were otherwise defective in VC that wouldn't be fixed until the next major release of the compiler, while Boost releases were every few months. Even trivial standard library things like std::ref, std::addressof, std::unique_ptr::~unique_ptr (wrong order of operations in VC10, fixed in VC11), std::align (wrong return value in VC11, fixed in VC12), std::call_once (was 1500 times slower than InitOnceExecuteOnce, fixed in VC14), the list went on. After a while, certain projects that dropped compatibility still chose to use Boost instead of the corresponding [now fixed] standard library facilities, just operating under the assumption that Boost would provide a higher quality of implementation, and more rapid rate of maintenance. Glen

2 1

failing accumulators tests
by Yuval Lifshitz 21 Feb '18

21 Feb '18

Dear All,Did anyone seen these failures on p_square_cumul_dist and weighted_median (latest checkout from github and gcc7.3.1/fedora27)? libs/accumulators/test/p_square_cumul_dist.cpp(66): error: in "p_square_cumulative_distribution test/test_stat": difference{0.0331329} between 0.5 * (1.0 + my_erf( histogram[i].first / std::sqrt(2.0) )){0.010331329148570989} and histogram[i].second{0.01} exceeds 3%libs/accumulators/test/p_square_cumul_dist.cpp(66): error: in "p_square_cumulative_distribution test/test_stat": difference{0.0372556} between 0.5 * (1.0 + my_erf( histogram[i].first / std::sqrt(2.0) )){0.020755484496021825} and histogram[i].second{0.02001} exceeds 3% libs/accumulators/test/p_square_cumul_dist.cpp(66): error: in "p_square_cumulative_distribution test/test_stat": difference{0.0326898} between 0.5 * (1.0 + my_erf( histogram[i].first / std::sqrt(2.0) )){0.030980693519017} and histogram[i].second{0.029999999999999999} exceeds 3% libs/accumulators/test/p_square_cumul_dist.cpp(66): error: in "p_square_cumulative_distribution test/test_stat": difference{0.0306804} between 0.5 * (1.0 + my_erf( histogram[i].first / std::sqrt(2.0) )){0.041227215128245343} and histogram[i].second{0.040000000000000001} exceeds 3% libs/accumulators/test/weighted_median.cpp(50): error: in "weighted_median test/test_stat": difference{0.0327894} between 1.{1} and weighted_median(acc_dens){0.96825159071079681} exceeds 3% libs/accumulators/test/weighted_median.cpp(51): error: in "weighted_median test/test_stat": difference{0.0316788} between 1.{1} and weighted_median(acc_cdist){0.96929395242297978} exceeds 3% Best Regards, Yuval

1 0

[release] 1.67.0 closed for major changes
by Daniel James 21 Feb '18

21 Feb '18

The master branch is now closed for new libraries and breaking changes, and will be closing for major changes in a week and closed for the beta in two weeks. Although I'm allowing HOF to merge a little late, as I haven't had much to time to check it for release this week. Also, if you're ready, you can also add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_67_0.q…> After editing the release notes, you should get a form to create a pull request, remember to submit it, otherwise I won't see your change. Also, a reminder that there are now templates for linking to github issues and pull requests. To link to a github issue use [github module-name issue-number] and to link to a pull request [github_pr module-name issue-number]. For example, to link to issue 24 from uuid, use [github uuid 24] which generates the text '#24'. Thanks, -- The Boost Release Team

1 0

C++03 / C++11 compatibility question for compiled libraries
by Raffi Enficiaud 20 Feb '18

20 Feb '18

Dear list, I have a technical question I do not know how to address, and I would like to know how people deal with this. To put things in the background: boost.test uses heavily boost::function and boost::bind, however I would like to use in some circumstances std::function and std::bind, which are, for instance, variadic. Boost.test is compiled with b2. I believe if the user does not pass additional parameters to the build, the default is to use whatever is provided in the Jamfile, that compiles the static and shared libraries in C++03 mode. If the user of boost.test compiles in C++03, it is ok if the library is used in a C++11 project. The other way is obviously not true. Now, in the headers of boost.test, I can detect for the compiler version, and depending on the language settings, activate an API that is C++11. OTOH, if I do not want users to be confused, this API should be header only. But this hardly work in practice, as the C++03 and C++11 APIs are usually not separable. Say: struct test_case { // compiled member function test_case(boost::function<void ()> function_to_test); #if Cpp11 // std::function variant to ensure compatibility with std::bind test_case(std::function<void ()> function_to_test); #endif private: boost::function<void ()> m_function_to_test; }; This API is obviously not good at all, and for having the slightest chance to make this work, the 2 APIs C++11 vs C++03 should be mutually exclusive. This also produces 2 different incompatible shared/static libraries, which is even more confusing for the user as the compiler options should be transitively passed to the user's code, or the user should be aware of which library to link with. So, the questions are: * how do other boost developers deal with this? * what is your experience on users in terms of compilation+linking? are usually people aware of this problem and they compile in C++11 all the code including boost? * is there any better option? All the other options I see are even worse. Thanks, Raffi

24 140

C++03 / C++11 compatibility question for compiled libraries
by Mike 20 Feb '18

20 Feb '18

Hello everyone, I hope it is ok, for me as a non-boost-dev, to chime in here. What I generally expect " dropping c++03 support" to mean are the following things: - Any library may start to use c++11 features at any point without prior announcement and/or without having to wait a few releases (I.e. it is no longer considered a breaking change). - c++03 builds are removed from the test matrices - Compilation paths that are c++03 only can be removed (thus simplifying the code base and future refactoring/development) - My hope (obviously no one can or should force a volunteer to do anything) is that - where applicable - libraries start to replace boost types & functions that have been merged into the c++11 standard with their std equivalent or the equivalent c++11 language feature. - In the long run, libraries that have been fully merged into c++11 could be deprecated and removed all together. Just to be clear: Dropping c++03 support doesn't mean a developer is forced to use c++11 constructs (if we ignore the potential future removal of boost libraries) - it primarily means that a user can no longer rely on the lib being usable in c++03 mode. And yes, this could be done on a per library basis, but especially older boost libraries are so tightly coupled that such decisions affect a lot of other libraries anyway. So my guess is that very few maintainers would dare to drop c++03 support as long as that hasn't been deemed acceptable by larger parts of the boost community.j Best regards Mike -- Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.

7 8

Review of Yap concluded today
by Louis Dionne 20 Feb '18

20 Feb '18

Dear Boost, The review of Zach Laine's Yap library concluded today, February 19th. I'd like to thank everyone who submitted a review or participated to the discussion in one way or another. The following reviews were submitted: - Barrett Adair (accept): https://lists.boost.org/Archives/boost/2018/02/241284.php - Alex Hagen-Zanker (reject/conditional accept): https://lists.boost.org/Archives/boost/2018/02/241296.php - Paul Fultz II (accept): https://lists.boost.org/Archives/boost/2018/02/241251.php - John Fletcher (accept): https://lists.boost.org/Archives/boost/2018/02/241212.php - Brook Milligan (conditional accept): https://lists.boost.org/Archives/boost/2018/02/241386.php - Steven Watanabe (accept): https://lists.boost.org/Archives/boost/2018/02/241442.php Please let me know if I've missed anyone. Also, for reference purposes, here are other notable general threads in the list archives that are related to the review: - Discussion on contextual evaluation of terminals: https://lists.boost.org/Archives/boost/2018/02/241092.php - Discussion on std::tuple vs hana::tuple: https://lists.boost.org/Archives/boost/2018/02/241351.php - Steven Watanabe on the documentation: https://lists.boost.org/Archives/boost/2018/02/241196.php - Steven Watanabe on the implementation: https://lists.boost.org/Archives/boost/2018/02/241281.php - Kickoff post: https://lists.boost.org/Archives/boost/2018/02/241076.php - Post extending the review until February 19th: https://lists.boost.org/Archives/boost/2018/02/241303.php I will summarize what was discussed during the review and announce the result of the review in a future post. Regards, Louis Dionne

1 0