- Boost - lists.preview.boost.org

Fwd: Re: [gsoc18][ublas] Proposal to add advanced matrix operations
by Mike Gresens 20 Jan '18

20 Jan '18

Hi Mike, Apart from the operations I was proposing, the idea of solving polynomials via QR reduction seems a great idea to me. I can add this module in the list of operations to be added to Boost.ublas in my proposal. I am looking for someone to mentor me on this project. Regards, Shikhar Srivastava On Sat, Jan 20, 2018 at 10:34 AM, SHIKHAR SRIVASTAVA <shikharsri1996(a)gmail.com <mailto:shikharsri1996@gmail.com>> wrote: Hi Mike, It looks like some of the operations that I suggested were already implemented as a part of GSOC15, though never got merged into the main branch. https://www.google-melange.com/archive/gsoc/2015/orgs/boostcpp/projects/raj… <https://www.google-melange.com/archive/gsoc/2015/orgs/boostcpp/projects/raj…> https://github.com/BoostGSoC15/ublas/ <https://github.com/BoostGSoC15/ublas/> My Idea was to add generalised modules for the operations (Now) - 1. LU and Cholesky 2. QR and QL 3. SVD On Fri, Jan 19, 2018 at 9:14 PM, Mike Gresens <mike.gresens(a)googlemail.com <mailto:mike.gresens@googlemail.com>> wrote: Hi Shikhar, does this include something for solving polynomials (via balanced-QR reduction of the companion matrix)? See https://www.gnu.org/software/gsl/doc/html/poly.html#general-polynomial-equa… <https://www.gnu.org/software/gsl/doc/html/poly.html#general-polynomial-equa…> Thanks! Best regards, Mike... Am 19.01.2018 um 07:37 schrieb SHIKHAR SRIVASTAVA via Boost: Hi everyone, I am a 4th year undergraduate student pursuing a degree in Computer Science and Engineering. I have strong programming experience in C++ through internships, self projects and programming events. I wish to be a part of gsoc18 under boost and am particularly interested in the linear algebra library Boost.ublas. The ublas library can be made more useful for Machine Learning applications like recommendation systems, clustering and classification, pattern recognition by adding some operations required in those. I propose to add advanced matrix operations to ublas including - 1. Triangular Factorisation (LU and Cholesky) 2. Orthogonal Factorisation (QR and QL) 3. Operations to find Singular Value lists 4. Eigenvalue algorithms 5. Singular Value Decomposition (SVD) 6. Jordan Decomposition 7. Schur Decomposition 8. Hessenberg Decomposition This is a very brief description of what I would like to propose. Any suggestions that help in refining the requirements before making a draft proposal would be great. Regards Shikhar Srivastava Github: https://github.com/shikharsrivastava <https://github.com/shikharsrivastava> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost <http://lists.boost.org/mailman/listinfo.cgi/boost>

1 0

[geometry][gsoc2018] Similarity between geometries
by Xing GUO 20 Jan '18

20 Jan '18

Hello, My name is Guo Xing, I have sent a mail for some ideas on gsoc18 projects. David's uBLAS project on GPU computation is a little bit hard for me. Still thanks for his kind reply :) . These days, I found a project that I could possibly work on. So, I decide to take "Similarity between geometries". Below is my short self-introduction. Name: Guo Xing University: Southeast University Major: Electronic Engineering Email: higuoxing(a)gmail.com Github: https://github.com/higuoxing Homepage: https://higuoxing.com Availability: (Feb-Jun 4 hr/day) (Jun-Aug 6hr/day or more) As for my code competency, I will take the project 1 competency test after my final exam. Thank you! Regards, Guo Xing

1 0

[callable_traits] Incorrect newlines in git
by Andrey Semashev 20 Jan '18

20 Jan '18

Hi, I've created this PR to fix newlines and tabs in Boost.CallableTraits: https://github.com/boostorg/callable_traits/pull/170 Without it, I cannot update my local Boost tree because git treats the files are modified. Could someone, please, merge this PR? It's really annoying that the update process breaks every time. Thanks.

2 1

[gsoc18] Implement HTTP Library
by Xing GUO 19 Jan '18

19 Jan '18

Dear community: I'm Guo Xing, who is currently a student in his third year of college(bachelor's degree). I have interests in web development. I've done some projects with Python and node before. I want to do some work with C++ in GSoC18. So, is there any ideas for me? Or, someone could be my mentor? I love open source, but never contribute to them. I want to do some contribution. Regards, Guo Xing https://github.com/higuoxing

3 2

crypto hash library
by kerukuro 19 Jan '18

19 Jan '18

While boost::hash and the proposed additions and are good for generic hashing, its API is not very suitable for cryptographic hashes and XOFs. Would there be any interest in boostifying this library eg under name 'boost::digest' and putting cryptographic hashes in there? https://github.com/kerukuro/digestpp

1 0

[gsoc18] R-tree serialization
by Kirill Mishchenko 19 Jan '18

19 Jan '18

Hi, My name is Kirill. I’m interested in the contribution to the project “R-tree serialization”. The search through the mailing list archive has shown there was an interest in this project among students in 2017, but as the GSoC 2017 archive site displays there was no student that participated to accomplish this project. Is it possible to work on this project as a GSoC 2018 participant? It seems like last year Adam Wulkiewicz was ready to be a mentor for the project. Briefly about myself. I am a PhD student working on Computational Humor. More precisely I’m working on the problem of finding/generating a humorous response given a textual input. My C++ programming experience includes a summer internship at Yandex Search and my contribution to mlpack (a machine learning library written in C++) as a GSoC 2017 participant (https://summerofcode.withgoogle.com/archive/2017/projects/4812231682293760/ <https://summerofcode.withgoogle.com/archive/2017/projects/4812231682293760/>). For mlpack I designed and implemented cross-validation and hyper-parameter tuning modules with significant usage of C++ metaprogramming. Best regards, Kirill Mishchenko

2 1

mingw and windows.h
by Raffi Enficiaud 18 Jan '18

18 Jan '18

Hi all, I recently pushed something for boost.test on develop that is apparently breaking the builds on mingw: http://www.boost.org/development/tests/develop/developer/output/igaztanaga-… What I do in the code is this: ---------- #ifdef _WIN32 #include <Windows.h> #endif ---------- and then later ---------- #ifdef _WIN32 class setcolor { protected: void set_console_color(std::ostream& os, WORD *attributes = NULL) const { DWORD console_type; /// some additional windows specific code #endif ---------- I thought that this would be enough for having the windows specific code, but apparently mingw disagrees with the error that some windows specific define is not there. Is this an issue with the code, the SDK, the machine? I have no experience with mingw, but if we are able to include windows.h, then we have to have the defines there (the missing macro is there since Windows 2000). Thanks for the help, Raffi

3 4

Google Summer of Code 2018: submit your proposal
by David Bellot 17 Jan '18

17 Jan '18

Hi all, I migrated the GSoC'18 pages to our wiki on Github. Please contribute your proposals here now: https://github.com/boostorg/boost/wiki/Boost-Google-Summer-of-Code-2018 I would love to see plenty of nice proposals before the end of the week so that we are in good conditions to obtain it again this year. If you have problems with permission please contact me directly Best regards, David

1 0

Change Trac wiki permissions
by David Bellot 17 Jan '18

17 Jan '18

Hi, does anyone have access to the boost Trac wiki. I need to change permissions on a page to allow users to edit the page as well, but I can't find any option. There should be an Admin button next to the Search button but it doesn't appear. The page in question is the Google Summer of Code 2018: https://svn.boost.org/trac10/wiki/SoC2018 Thanks David

2 2

Reforming Boost.System and <system_error> round 2
by Niall Douglas 17 Jan '18

17 Jan '18

Many thanks to those who have contributed to the discussion in the other thread regarding making a breaking change to Boost.System in order to provide empirical test data to persuade WG21 to similarly break <system_error> in a future C++ standard for its own good. This fresh email is hopefully to start finishing the discussion. To summarise discussion to date, Peter has made Boost.System's error_code and error_category constexpr except for the virtual functions. A big win for codegen, and the choice of the default constructor of error_code to use system_category now no longer prevents constexpr, so the request for a new special null_category() can also be dropped. There is substantial opposition to making message() return string_view, so let's drop that request. That leaves the request to fix "if(ec) ..." which right now returns true if the value is 0, despite that much code writes "if(ec) ..." to mean "if error then ...". There is also the issue of error coding schemes not being able to have more than one success value, which usually must be 0. That's the remaining discussion point. Myself and Peter feel this is worth fixing despite the increased runtime overhead. Others, including one of its original inventors, feel it is too much overhead. To add some empirical evidence to the discussion, I have coded up a mock up of the improved error_code which can be viewed at https://godbolt.org/g/dDAWih. This demonstrates constexpr error_code and error_category in action as well. To summarise what the mock up demonstrates: 1. error_category() gains a new virtual function called `bool failure(int code)` which is now called by error_code's operator bool. 2. Thanks to the new constexpr construction, the compiler now completely elides from runtime the case where an inlined function returns an error code and the caller acts upon it. As in, **zero code is now generated**. Far better than before. No virtual functions are called, they are optimised out entirely. 3. For unknown error codes from extern sources where the linker is generating an executable, the "final" modifier removes a layer of indirection when calling `failure()` after the linker has run, and indeed clang seems to go ahead and inline the implementation entirely despite us not asking for LTO. Which is kinda cool. 4. Thus only in shared objects, and only for unknown error codes from extern sources, is a virtual function call actually performed. And given the frequency of doing `if(ec) ...`, it'll almost certainly be hot in the branch predictor i.e. no stalls. Question: is this still considered too much overhead? Note that there is no longer ANY proposed breaking change with existing code. This is now 100% enhancement only. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

17 57

[GSoC2018] About Summer Projects of Boost
by 郭兴 17 Jan '18

17 Jan '18

Hi, there, GSoC2018 is coming, I am in my third year of college(bachelor's degree) and want to be enrolled in this interesting program as student. I want to do some contribution for community. Are there some open projects? Maybe I could do some work? I am interested in [geometry], [ublas] and [asio]. I think I could prepare for it from now on. Cheers, Xing GUO

3 2

Re: [boost] Reforming Boost.System and <system_error> round 2
by Andrey Semashev 17 Jan '18

17 Jan '18

On Wed, Jan 17, 2018 at 2:44 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > 2018-01-17 0:29 GMT+01:00 Andrey Semashev <andrey.semashev(a)gmail.com>: >> >> On Wed, Jan 17, 2018 at 1:16 AM, Andrzej Krzemienski via Boost >> <boost(a)lists.boost.org> wrote: >> > 2018-01-16 19:58 GMT+01:00 Andrey Semashev via Boost >> > <boost(a)lists.boost.org> >> > : >> >> >> >> There's nothing ambuguous about the conversion operator, as it is >> >> specified in the standard, and I find the syntax quite intuitive. >> > >> > You say you find the syntax quite intuitive. But do you also find the >> > semantics intuitive? When you type or read `if(ec)` do you interpret it >> > as >> > "if operation failed" or as "if operation returned code of numeric value >> > zero, regardless of the domain and regardless of whether in this domain >> > zero means success or failure"? >> >> The two interpretations are equivalent for me, because in my code >> error code of zero always means "success". Why? Because I pick the >> error values that way (or map them that way, if the values come from >> an external API) so that they play nicely with `error_code` design and >> the rest of the code. >> >> If we support multiple "success" values or non-zero success values, I >> would expect "if (err)" to mean "if some error happened". Why? Because >> that "if" controls error handling, not an arbitrary non-zero result >> handling. I've never seen or written code that does otherwise. >> >> If I want to test for a particular error code, I would write "if (err >> == x)" or "if (err != x)" - that's the syntax that communicates the >> intent to check for the particular value, including when `x` happens >> to be zero (which doesn't really matter, because `x` is always an enum >> value and never a magic number). You may ask the what is the >> difference between "if (err)" and "if (err != success)" and it is that >> the latter only tests for failure in the particular domain. Now, this >> difference may not be obvious, and that is why I generally avoid >> writing "if (err != success)". > > Yes, that would also be my expectation. So, if I understand your position > correctly, you oppose to introducing yet another function `failure(ec)`, but > you would be ok with fixing `if(ec)` so that it always means "failure" (of > course provided that you can be convinced that there is anything that needs > fixing). Yes. Not actively opposed, though. I just don't see the point in having this more verbose syntax for something that we already have and that is more succint. I'm not opposed to adding support for multiple success codes, quite the opposite. My only condition is that this enhancement doesn't penalize too much the existing usages with a single zero success code. > It has been always my understanding that `error_code` is intended to be used > so that the numeric value is always *exactly* the value returned by the > system call: you do not change it, do not adapt it. You keep it unchanged so > that when logged, the programmer can easily retrieve the original number say > from the log file to check what went wrong with the system call. Instead, > you use all this machinery with conditions to perform different queries, on > what kind/sort of failure it was. > > Now, if you adapt the error code so that 0 means success and non-0 means > failure, you are violating this idea that numeric value of `error_code` > should be delivered unchanged, un-adapted. Mapping foreign success codes to zero may be viewed as a hack, but in practice it rarely matters. When you present error codes to the user, you rarely want to present the numeric value. Most likely, you want to present the human-readable result of `message()`, and it will be produced using the mapped error code values. I agree that ideally you would not have to map error codes, but that is an acceptable compromise to have a decent performance and unified syntax with the existing `std::error_code`. Hopefully, if we settle on an efficient solution, we won't have to do this anymore.

1 0

Upcoming formal review of the [Boost.]Yap library
by Louis Dionne 16 Jan '18

16 Jan '18

Hi everyone, The formal review of Zach Laine's 'yap' expression template library will be starting in 3 weeks, from Feb 05 to Feb 14. yap is a C++14-and-later library to build expression templates, much like Boost.Proto currently does. yap uses new features introduced in C++14/17 to make the library simpler to use and compile faster than existing solutions. The documentation is available here: https://tzlaine.github.io/yap The official repository is here: https://github.com/tzlaine/yap We encourage folks to become familiar with the library and submit feedback to the author even before the review starts. Thanks! Louis Dionne (review manager for this submission)

1 0

[convert][align][coroutine2][dll][endian][fiber][metaparse][check_build][qvm] Missing .gitattributes
by Steven Watanabe 15 Jan '18

15 Jan '18

AMDG I noticed that the following submodules have no .gitattributes: convert align coroutine2 dll endian fiber metaparse tools/check_build Also, qvm forces Windows line endings in its .gitattributes In Christ, Steven Watanabe

1 0

Bug report rejected as conformant
by Edward Diener 13 Jan '18

13 Jan '18

I recently reported a preprocessor bug in Oracle C++ 12.6 on their online forum when compiling a C program example. I even cited the C11 standard in showing that Oracle C++ 12.6's actions were non-conformant. The answer I was given, from an Oracle C++ developer who said he was a member of the C++ standard committee, is that since Oracle C++ 12.6 gives a warning message rather than a compiler error the compiler was compliant with the C standard, since the standard only requires a diagnostic message to be considered standard compliant when it does not implement the compiler according to the standard, and that a warning was a diagnostic message. Furthermore since there was a way to force the particular warning to be considered an error, Oracle was not going to change their compiler. At that point I "lost it" so to speak. I cannot conceive that any C/C++ standard would specify that giving a warning rather than an error, when not complying with the C/C++ standard, would then make the compiler compliant. Comments ?

5 11

[git] Git problem with Boost
by Edward Diener 13 Jan '18

13 Jan '18

git checkout develop git pull git submodule update --init from my local main Boost repository gives me: error: no such remote ref 0ce9138ce86095eab9c09d171fecb5f72c4457f7 Fetched in submodule path 'libs/callable_traits', but it did not contain 0ce9138ce86095eab9c09d171fecb5f72c4457f7. Direct fetching of that commit failed.

3 4

Re: [boost] Potential Boost SAX library
by Bjorn Reese 13 Jan '18

13 Jan '18

On 01/09/18 18:36, Oliver Adams via Boost wrote: > I was wondering if a library I'm developing would be of value to the > Boost community. It is basically an event-driven parsing/serialization > library for common formats using a standard internal representation or > simple pass-through conversions. Would anyone be interested in something > like this being added to Boost? There are two kinds of incremental parsers: push parsers (SAX) and pull parsers (approximately StAX.) Briefly put, push parsers traverses the input automatically and generates events for each token it finds, whereas pull parsers traverses the input manually like an iterator and the current token can be queried. Pull parsers have some significant advantages over push parser: * It is straight-forward to implement a push parser on top of a pull parser. This involves a loop and a switch statement (see [1] for a complete example.) Going in the other direction involves the use of coroutines; most likely stateful coroutines. * Contextual parsing can be done directly, unlike push parsers where you have to maintain contextual state in the event handler. * Push parsers can be used directly in Boost.Serialization archives. * Pull parsers are composable. For instance, you could insert a URL pull parser directly into an HTTP pull parser. For a pull parser framework see: https://github.com/breese/trial.protocol The documentation is a bit old though. [1] http://breese.github.io/trial/protocol/trial_protocol/json/tutorial/push_pa…

3 2

Re: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?
by Bjorn Reese 13 Jan '18

13 Jan '18

On 01/12/18 18:43, Niall Douglas via Boost wrote: > 2. Success becomes solely the default constructed error code, which is > code zero and a new category of "null_category". This is internally > represented by { 0, nullptr }, and thus makes the default constructor > trivial which is highly desirable as it eliminates any compiler magic > static fencing for the default constructor. Right now the default > constructor uses system_category with value 0, and I suspect no code > will notice this change either. Does this mean that custom error categories have to change their make_error_code(e) function to either return a default constructed error_code in case the error value indicates success, or a custom error_code otherwise? In other words, today we do this: namespace my { std::error_code make_error_code(my::errc e) { return std::error(e, my::category()); } } Should that be changed to this? namespace my { std::error_code make_error_code(my::errc e) { if (e == my::success) return std::error_code(); return std::error_code(e, my::category); } }

1 0

[date_time] building documentation?
by James E. King, III 12 Jan '18

12 Jan '18

I cannot build the documentation for Boot.DateTime on the develop tip - I get an error - am I doing something wrong in the command line or is it just broken? jking@ubuntu:~/boost/libs/date_time/doc$ ../../../b2 boostdoc Performing configuration checks - default address-model : 64-bit - default architecture : x86 ../xmldoc/Jamfile.v2:54: in modules.load *** argument error * rule doxygen ( target : sources + : requirements * : default-build * : usage-requirements * ) * called with: ( date_time_autodoc : : <doxygen:param>ENABLE_PREPROCESSING=NO <xsl:param>boost.doxygen.reftitle=Date Time Reference <doxygen.doxproc.title>Date Time Reference <doxygen.doxproc.id>date_time_reference ) * missing argument sources /home/jking/boost/tools/build/src/tools/doxygen.jam:622:see definition of rule 'doxygen' being called /home/jking/boost/tools/build/src/build/project.jam:325: in load-jamfile /home/jking/boost/tools/build/src/build/project.jam:64: in load /home/jking/boost/tools/build/src/build/project.jam:145: in project.find /home/jking/boost/tools/build/src/build/targets.jam:401: in find-really /home/jking/boost/tools/build/src/build/targets.jam:474: in class(a)project-target.find /home/jking/boost/tools/build/src/build/targets.jam:858: in resolve-reference /home/jking/boost/tools/build/src/build/targets.jam:875: in targets.generate-from-reference /home/jking/boost/tools/build/src/build/targets.jam:1226: in generate-dependencies /home/jking/boost/tools/build/src/build/targets.jam:1280: in class(a)basic-target.generate /home/jking/boost/tools/build/src/build/targets.jam:770: in generate-really /home/jking/boost/tools/build/src/build/targets.jam:742: in class(a)main-target.generate /home/jking/boost/tools/build/src/build-system.jam:796: in load /home/jking/boost/tools/build/src/kernel/modules.jam:295: in import /home/jking/boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build /home/jking/boost/boost-build.jam:17: in module scope

3 10

[date_time] [build] new windows class of build error?
by James E. King, III 12 Jan '18

12 Jan '18

I enabled appveyor for Boost.DateTime pull requests and they are failing miserably when <cxxstd> is specified more than once. I don't remember this occurring in the past. This happens on Visual Studio, cygwin, mingw builds. Is this new Boost.Build behavior? https://ci.appveyor.com/project/jeking3/date-time-1evbf/build/1.0.3-develop error: Name clash for '<pstage\lib>libboost_atomic-vc140-mt-x32-1_67.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <cxxstd>14 error: - <cxxstd>17 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. Command exited with code 1

2 1

Informal CMake meeting at CPPCon
by Robert Ramey 12 Jan '18

12 Jan '18

Thursday 28 Sept 8 AM at CPPCon a small group of us met to talk a little regarding the situation regarding support of CMake by Boost. I promoted this meeting as I've been concerned that the only discernible results of the recent Boost Steering Committee announcement on the subject was a certain level of antagonism among boost members regarding the subject. Participants ============ Robert Ramey (me) Rene Rivera Vinnie Falco Louis Dionne David Sankel Matt Calabrese This was a small but I think a representative group. After some preliminary back and forth, I think we agreed: a) Nothing was going change regarding the current build system until there was a real alternative in place. b) That we should support serious proposals to implement CMake support within boost. c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice. d) Questions regarding the scope/implemention of such support for CMake can be handled within the formal review process. e) Other questions regarding support CMake and Boost, transition to new system, related requirements on boost libraries, etc. can be better addressed once we have some sort of consensus on the form that CMake support will take. I had contacted Paul Fultz who is the only one I know of that has proposed something specific to submit to formal review. He told me he couldn't do it at the time, but shortly there after posted such a request on the list. So I guess for now we're on our way. My motivation for posting this is to keep the boost community up to date on what's happening so that no one gets overly surprised when things start to happen. I'm not really soliciting feedback - though it wouldn't surprise me if I get some. Robert Ramey

9 18

[scope_exit] (Boost >= 1.65) VS 2015 internal compiler error in lambda
by Tobias Loew 12 Jan '18

12 Jan '18

Hi, starting from Boost version 1.65 and using VS 2015 Update 3 (MSVC 19.00) the following code raises an internal compiler error: fatal error C1001: An internal error has occurred in the compiler. (compiler file 'msc1.cpp', line 1468). With earlier Boost versions it compiles fine. Tobias -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

3 8

Issue with bjam and building for NDK
by Robert Dailey 11 Jan '18

11 Jan '18

I filed an issue over at the Android NDK github page here: https://github.com/android-ndk/ndk/issues/616 When I invoke b2 to build boost using the standalone toolchain generated by the NDK, bjam seems to be wrapping the command in quotes, like "clang++". This throws off their logic in the clang++.cmd batch script. I was asked to test running b2 without quotes (e.g. clang++), but I am not sure how to do this. Could someone help me understand if this is a code change to b2? Or if there's a jam script somewhere I can modify? I'm not sure if this is a boost issue or an NDK issue at this point. I appreciate any help from the boost developers.

2 1

[contract] ready to release
by Lorenzo Caminiti 10 Jan '18

10 Jan '18

Hello release managers & all, Boost.Contract in master is ready to be added to the next Boost release (regression tests pass, docs are updated, etc.). What do I have to do to put https://github.com/boostorg/contract.git master into Boost release 1.67? Thank you. --Lorenzo

2 3

Potential Boost SAX library
by Oliver Adams 10 Jan '18

10 Jan '18

Hi all, I was wondering if a library I'm developing would be of value to the Boost community. It is basically an event-driven parsing/serialization library for common formats using a standard internal representation or simple pass-through conversions. Would anyone be interested in something like this being added to Boost? Thanks.

4 6