February 2018 - Boost - lists.boost.org

regarding gsoc 2018
by Akshay Raut 23 Feb '18

23 Feb '18

hello everyone i am from india doing bachelors in computer science. I am very passionate for c++ and hence, I want to contribute to it through this organization in this year's gsoc. can someone please tell me the best way to get started so that i get selected this year??

2 1

[yap] Re-announcing Yap
by Zach Laine 23 Feb '18

23 Feb '18

I posted 2-3 months ago about Yap, an expression template library I've written that I intend to propose for Boost. This is just a reminder that the library exists, and where to find it. I'm giving a talk about it at C++Now 2017, and some time after that I intend to submit it to the queue. Louis Dionne has offered to serve as review manager when the time comes. You can find the main repo on GitHub: https://github.com/tzlaine/yap And online docs are here: https://tzlaine.github.io/yap Zach

4 6

Query for interest in library: reflective enum
by Nir Friedman 23 Feb '18

23 Feb '18

Hello, I recently needed a reflective enum for work (that is an enum where you can programmatically convert to and from strings, know how many enumerators there are, and iterate over all enumerators). I looked online but I didn't find anything that met my requirements. I was surprised that there wasn't one in Boost. So I'd like to see if there is interest; I wrote an implementation that I think has several nice features. The most polished existing smart enum implementation I could find was http://aantron.github.io/better-enums/. However, the enum implemented there is not a true enum; it uses a nested member of a class kind of approach. So for example, the is_enum type trait will not recognize is as an enum. You cannot use it as a non-type template parameter. I strongly think that a good generic smart enum macro should generate the exact "vanilla" enum (or enum class) declaration. My library's syntax looks like this: WISE_ENUM(Foo, BAR, (BAZ, 3)) This generates, among other things, exactly: enum Foo { BAR, BAZ=3}; I intend this as an explicit guarantee of the library that the programmer can count on. That way when Foo is used for things unrelating to reflection, the developer can be confident that there will not be any surprises. Beyond compatability with C++ facilities for enums, and minimizing surprise, another advantage of this approach is that it's guaranteed to be backwards compatible. An existing codebase with an existing enum/enum class can switch to this smart enum with very high confidence that existing code will continue to work as before. The WISE_ENUM macro, beyond generating the vanilla enum, also generates a switch-case function for to-string conversion (for maximal efficiency), and finally it generates a constexpr function that returns a std::array<std::pair<const char*, Foo>> listing all of the arrays and their string descriptions. This constexpr function, which is found via ADL, allows writing a sequence of (constexpr) variables and functions providing the rest of the desired functionality. Usage looks like this: std::cerr << "My enum's size is : " << wise_enum::size<Foo> // this is constexpr template variable auto x = wise_enum::from_string<Foo>("BAR").value(); // from_string returns an optional auto y = wise_enum::to_string(x); // y is string literal, no heap allocation My implementation (POC level) is here: https://github.com/quicknir/wise_enum. I don't yet have separate macros to cover enum/enum class/explicit/implicit backing type combinations. It's only about 100 lines of code, leaning heavily on BOOST_PP to do the heavy lifting. It requires variadic macros, and can probably target C++11 (if it doesn't already). I probably need to "comma harden" the macros for bizarre stuff like WISE_ENUM(Foo, (BAR, my_func<3,4>())). It has the limitation that the macro cannot be used inside a class (this is hard to workaround for reflective macros). It's also unclear how repeated enumeration values would be handled (enum Foo { BAR = 1, BAZ = 1}). As it stands this will cause a compilation failure in the generated switch case of the to_string function. Can discuss more in subsequent emails. One suggested feature is an is_contiguous trait. Another reasonable bit of functionality might be an is_wise_enum trait. Version 2 of this library could target enum sets. Although it's not fancy, I think this nicely covers a piece of functionality I often need, and it does so avoiding any downside compared to using a simple enum (beyond having to use macros). Hope other people will agree! Cheers, Nir

4 5

[Math] Only a fraction of the tests showing up online
by John Maddock 23 Feb '18

23 Feb '18

I assume this is an issue with the test matrix, but only about 1/3 of the Math lib tests are showing up at http://www.boost.org/development/tests/develop/developer/math.html Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 4

[gsoc18] - Similarity Between Geometries and Timeframe Question
by Aidan Nyquist 23 Feb '18

23 Feb '18

Hello, My name is Aidan Nyquist, a sophomore at North Park University. I'm currently majoring in Math and Physics, and minoring in computer science. I have been programming for about 4 years now, and have experience with a fair amount of languages (Python, C/C++, Java, LISP, Haskell, SQL, etc.). Sifting through all the GSoC projects, while fun, can be somewhat difficult. I have just found the "Similarity between geometries" project and think I am a great fit. I wish I had found it sooner though, so I could have started the evaluation test done by now. Is there a rough deadline for its submission? I'm applying for one other organization, and they had a Feb. 28 deadline. If there is a similar date, I will reluctantly not attend the Hackathon I was hoping to go to this weekend. However, if there is some buffer time, that would be great to know, so I could be at ease. Any advice is always appreciated. Thanks, Aidan Nyquist

2 1

Yap's formal review is starting now!
by Louis Dionne 23 Feb '18

23 Feb '18

Dear Boost community, The formal review of Zach Laine's Yap library starts Monday, February 5th and ends on Wednesday, February 14th. Yap is a C++14-and-later library to build expression templates. Yap uses new features introduced in C++14/17 to make the library simpler to use and compile faster than existing solutions, such as the well known Boost.Proto library. The documentation is available here: https://tzlaine.github.io/yap/doc/html/index.html The GitHub repository is available here: https://github.com/tzlaine/yap We encourage your participation in this review. At a minimum, please state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? All issues discussed during this review will be tracked on the library's GitHub issue tracker at https://github.com/tzlaine/yap/issues. Regards, Louis Dionne P.S.: I've been having trouble posting to this list. If this ends up being a duplicate post, let's make this one the official one.

14 107

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

[gsoc 18] - Enhancing Boost.Intrusive Library
by harisaicharan.challa＠gmail.com 19 Feb '18

19 Feb '18

Hello Boost community, I am Hari sai charan challa, 3rd year undergraduate student from International Institute of Information Technology, Hyderabad (IIIT). I have been working on boost-libraries since 2 months, trying to fix a bug.I can code efficiently in C++ .I have good knowledge in Data structures and Algorithms.I am interested in "Enhancing Boost.Intrusive Library" project so i am looking for a mentor to guide me in this project.

3 3

(no subject)
by karan singh 18 Feb '18

18 Feb '18

hello all , i want to contribute for boost and want to participate in gsoc18. i have c++ knowledge but dont know where to start.

2 1

[gsoc 18] Enhancing Boost.Intrusive Library
by harisaicharan.challa＠gmail.com 18 Feb '18

18 Feb '18

Hello, I am Hari.I am working on competency test of "Enhancing Boost.Intrusive library" project , so can someone please elaborate on the following requirement for the competency test. Requirement:- Test programs for ensuring accuracy and performance benchmark tests against various type of solutions (brute-force, recursive, iterative) Thank-you.

1 0

(no subject)
by karan singh 18 Feb '18

18 Feb '18

hi all , i want to contribute for boost , can anyone help i am a newbie

1 0

Moving Boost.HigherOrderFunctions(formely know as Fit) to boostord
by paul 15 Feb '18

15 Feb '18

Hi All, Can someone with Admin access help me move my repo to boostorg? Thanks, Paul

2 3

[GSoC'18] Project : Add support for tensors
by Manan Sharma 15 Feb '18

15 Feb '18

Hello Boost Community, My name is Manan Sharma. I am a 3rd year undergraduate student pursuing my B.Tech in Computer Science and M.S by research in IIIT Hyderabad, India. I have good understanding of Linear Algebra and Machine Learning. I have a sound background in data structures and algorithms and have qualified twice for ACM ICPC regionals. I have secured good rank in other programming contests too. I have good understanding of C++ having done all my competitive programming and several different projects using it. I am interested in project for adding support for tensors in uBLAS. Since I am new to open source, please let me know as to how can I get started. Thanks Manan Sharma

2 1

Can't build docs in downloaded Boost 1.66 sources
by Zach Laine 15 Feb '18

15 Feb '18

I came across this while trying to build the Yap docs, outside the Boost source tree. It turns out it doesn't work in the Boost source tree either. This: cd ~/boost_1_66_0 ./bootstrap.sh cd libs/units/doc ~/boost_1_66_0/b2 used to work (not sure how long ago). Now it says this: tzlaine@linux-desk:~/boost_1_66_0/libs/units/doc$ ~/boost_1_66_0/b2 Performing configuration checks - 32-bit : no (cached) - 64-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : yes (cached) BoostBook warning: no DocBook XSL directory specified. If you have the DocBook XSL stylesheets installed, please set DOCBOOK_XSL_DIR to the stylesheet directory on either the command line (via -sDOCBOOK_XSL_DIR=...) or in a Boost.Jam configuration file. The DocBook XSL stylesheets are available here: http://docbook.sourceforge.net/ Stylesheets will be downloaded on-the-fly (very slow!) ...patience... ...patience... ...patience... ...found 2671 targets... ...updating 2 targets... xslt-xsltproc ../../../bin.v2/libs/units/doc/gcc-gnu-7/debug/threadapi-pthread/units.docbook http://docbook.sourceforge.net/release/xsl/current/common/common.xsl:1: parser error : Start ta g expected, '<' not found Project web is currently offline pending the final migration of its data to our ^ compilation error: file /home/tzlaine/boost_1_66_0/tools/boostbook/xsl/docbook.xsl line 12 elem ent import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/common/common.xs l XML_CATALOG_FILES="../../../bin.v2/boostbook_catalog.xml" export XML_CATALOG_FILES "xsltproc" --stringparam boost.defaults "Boost" --stringparam boost.root "../../../.." --strin gparam chunk.section.depth "8" --stringparam toc.max.depth "1" --stringparam toc.section.depth "8" --xinclude -o "../../../bin.v2/libs/units/doc/gcc-gnu-7/debug/threadapi-pthread/units.docbo ok" "/home/tzlaine/boost_1_66_0/tools/boostbook/xsl/docbook.xsl" "../../../bin.v2/libs/units/do c/gcc-gnu-7/debug/threadapi-pthread/units.xml" ...failed xslt-xsltproc ../../../bin.v2/libs/units/doc/gcc-gnu-7/debug/threadapi-pthread/units. docbook... ...skipped <phtml>standalone_HTML.manifest for lack of <p../../../bin.v2/libs/units/doc/gcc-gnu -7/debug/threadapi-pthread>units.docbook... ...failed updating 1 target... ...skipped 1 target... That's the full output from doing the build a second time, FWIW. Some of the steps the first time said the same thing, but it seemed too much to post. Anyone know what's doing on? Zach

2 2

New developer interested in working on the Project 1 of Boost.ublas for GSoC18
by pranay gupta 14 Feb '18

14 Feb '18

Hello everyone, My name is Pranay Gupta I am a second year computer science undergrad at IIIT Hyderabad, Im new here at Boost. I was very much interested in doing the first project of Boot.uBLAS which was about adding statistical and machine learning functions to Boost.uBLAS and have started with the competency test. Can someone please guide me as to how should I share my competency test with the mentors and improve it further. Thank You, Yours Sincerely, Pranay Gupta

2 1

Re: [boost] [yap] Review
by P F 14 Feb '18

14 Feb '18

> On Feb 14, 2018, at 1:38 PM, Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Tue, Feb 13, 2018 at 8:24 PM, P F <pfultz2(a)yahoo.com <mailto:pfultz2@yahoo.com>> wrote: > >> On Feb 12, 2018, at 7:57 PM, Zach Laine via Boost <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> wrote: >> >> On Mon, Feb 12, 2018 at 4:15 PM, P F via Boost <boost(a)lists.boost.org <mailto:boost@lists.boost.org>> >> wrote: >> >> I actually experimented with trying to remove the Hana bits for this exact >> reason. The conclusion I came to was that writing the library was quite a >> bit harder in a couple of places, but that's not too bad. The bigger >> problem is that the lack of algorithms over std::tuple for users of the >> library when they write transforms. Maybe we should talk offline about how >> to do things that are done now with Hana, with Fit instead. > > Actually, the main algorithms you use are transform, for_each, and unpack, which is trivial to do with Fit. Doing a `zip` or `filter` is a little more complicated, but grepping the source code, I did not see that. I discuss how thats done here: > > http://pfultz2.com/blog/2015/09/12/power-of-unpack/ <http://pfultz2.com/blog/2015/09/12/power-of-unpack/> > > Which we can discuss more offline. > > I also use Hana constants all over the place. Yes, but it should be simple to move from `0_c` to `c<0>{}`. Ultimately, it really should be moved to a separate library, because even Boost.TypeTraits could use these “enhanced” integral constants(but that is another discussion). >>> by just taking it as a type and using something similiar to `mp_transform` >>> to change the parameters. Or even change `Kind` to be a type of >>> `std::integral_constant<boost::yap::expr_kind, Kind>` so `mp_transform` >>> could be used directly: >>> >>> template <typename Kind, typename Tuple> >>> struct user_expr : logical_not<user_expr> >>> { >>> static const boost::yap::expr_kind kind = Kind{}; >>> >>> Tuple elements; >>> }; >>> >> >> You certainly could. What does this buy, though? > > Being able to use `mp_assign` to change the parameters to `user_expr`. Although, you could write your own version which allows the first parameter to be an integral. > > Ok, but all of the above is still the "what". I want the "why". Why is it better to be able to use mp_assign? >> I'm not getting that >> part yet. One thing this give up is the inability to write functions in >> terms of chained >> >> constexpr if (kind == expr_kind::foo) >> >> statements, which I quite like. You can do this with is_same<> of course, >> but at the cost of 45 extra template instantiations and a lot more noise. > > That should still work. I dont see why it wouldn’t. In fact, you should be able to do all of these: > > template<boost::yap::expr_kind Kind> > using expr_kind_c = std::integral_constant<boost::yap::expr_kind, Kind>; > > constexpr if (kind == expr_kind_c<foo>{}) > constexpr if (Kind{} == expr_kind_c<foo>{}) > constexpr if (kind{} == expr_kind::foo) > > What may not work is doing something like `fit::if_(Kind{} == expr_kind_c<foo>{})`(due to lack of operator overloading for integral_constant), but using `fit::if_c<Kind{} == expr_kind_c<foo>{}>` still does work. > > Right, but all of that is noisier than what I currently have. Not really because `constexpr if (kind == expr_kind::foo)` will still work. > If there are advantages to using mp_assign, maybe this extra noise in a few places is worth it. I still have no idea what the mp_assign advantages are though. The point is to be able to get rid of `::` at the beginning in `BOOST_YAP_USER_UNARY_OPERATOR_MEMBER(logical_not, ::user_expr)`. If the user forgets those, you need to have a clear way to tell the user they need to add them, because it may not be obvious from the compiler error without understanding the implementation details. One way to solve this is to avoid it altogether by not passing a template, which you can try to utilize something like mp_assign. Another possible solution may be to add a static_assert with a message like “you are passing a type instead of template, you may need to prepend :: to the parameter to this macro". I think you can use function overloading to distinguish between a type and a template, but I am not sure. Paul

4 3