Rene Rivera | 27 Jan 16:36 2015
Picon

[release] Release schedule changes..

After some discussion in the Boost Release Team we've decided on an ongoing schedule for releases. Taking into account the realities of how long it takes for authors and the release team to work on a release we've decided to move to *three* releases a year. The targets for the releases will now be:

* Spring release on the second Wednesday of April.
* Summer release on the second Wednesday of August.
* Fall/Winter release on the second Wednesday of December.

There will be no January release. This will allow for the fact that most people are on extended holidays during Winter. It will also allow for people to work on larger changes that require more testing time during the longer Winter period. We are also moving to Wednesday release to allow the release managers non-weekend time to work before and after the release.

Please consult the Boost calendar for specific dates and merge schedule for the next release.

Thanks, the Boost Release Team.

--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
<div><div dir="ltr">After some discussion in the Boost Release Team we've decided on an ongoing schedule for releases. Taking into account the realities of how long it takes for authors and the release team to work on a release we've decided to move to *three* releases a year. The targets for the releases will now be:<div><br></div>
<div>* Spring release on the second Wednesday of April.</div>
<div>* Summer release on the second Wednesday of August.</div>
<div>* Fall/Winter release on the second Wednesday of December.</div>
<div><br></div>
<div>There will be no January release. This will allow for the fact that most people are on extended holidays during Winter. It will also allow for people to work on larger changes that require more testing time during the longer Winter period. We are also moving to Wednesday release to allow the release managers non-weekend time to work before and after the release.</div>
<div><br></div>
<div>Please consult the Boost calendar for specific dates and merge schedule for the next release.</div>
<div><br></div>
<div>Thanks, the Boost Release Team.<br><div><div>
<div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">-- Rene Rivera<br>-- Grafik - Don't Assume Anything<br>-- Robot Dreams -&nbsp;<a href="http://robot-dreams.net/" target="_blank">http://robot-dreams.net</a><br>-- rrivera/<a href="http://acm.org/" target="_blank">acm.org</a>&nbsp;(msn)&nbsp;-&nbsp;grafikrobot/aim,yahoo,skype,efnet,gmail</div></div>
</div></div>
</div>
</div></div>
Joel FALCOU | 23 Jan 17:17 2015
Picon

[Review] Boost.Endian mini-review

The mini-review of Boost.Endian starts today and runs through Sunday,
February 1.

The library repository is available on GitHub at
https://github.com/boostorg/endian

The docs for the library can be viewed online at
https://boostorg.github.io/endian/

The objective of the mini-review is to verify that the issues raised
during the formal review have been addressed. Those issues are
documented at https://boostorg.github.io/endian/mini_review_topics.html
which also describes the resolution of each issue.

Comments and suggestions unrelated to the mini-review issues are also
welcome, but the key question the review manager needs your opinion on
is this:

    Is the library ready to be added to Boost releases?

-- Joel Falcou, Endian Review Manager
Ron Garcia | 23 Jan 04:29 2015
Picon

Review Wizard Status Report for January 2015


==============================================
Review Wizard Status Report for January 2015
==============================================

News
====

1. Boost 1.56 Released November 2014. New Libraries: none
2. Sort Accepted. November 2014.
3. Compute Accepted. December 2014.

Open Issues
===========

The following libraries have review managers, but have not yet been
scheduled for review:

* Range Extensions - added May 2012; review manager: Neil Groves.

The following libraries have been accepted to Boost, but have not yet
been integrated into Boost Git:

* Contract - accepted September 2012; author: Lorenzo Caminiti.
* Sort - accepted November 2014: author: .
* Compute - accepted December 2014: author: .

The following libraries have been accepted and submitted to Boost Git, but
have not yet appeared in a release:

* Convert - accepted June 2014; author: Vladimir Batov.

The following libraries have been accepted provisionally to Boost, but
have not been submitted for mini-review and full acceptance:

* Endian - accepted provisionally September 2011; author Beman Dawes.
* Fiber - accepted provisionally January 2014; author Oliver Kowalke.

General Announcements
=====================

As always, we need experienced review managers.  Please take a look at
the list of libraries in need of managers and check out their
descriptions. In general review managers are active boost
participants, including library contributors, infrastructure
contributors, and other mailing list participants with a substantial
track record of constructive participation. If you can serve as review
manager for any of them, email Ron Garcia or John Phillips, "rxg at cs
dot ubc dot ca" and "johnphillipsithica at gmail dot com" respectively.

We are also suffering from a lack of reviewers. While we all
understand time pressures and the need to complete paying work, the
strength of Boost is based on the detailed and informed reviews
submitted by you.  If you are interested in reviewing a library but
won't have time during the review period, you can always prepare your
review ahead of time.  No rule says you can only work on a review
during the review period.

A link to this report will be posted to www.boost.org. If you would
like us to make any modifications or additions to this report, please
email Ron or John.

The review schedule is an unordered list of the libraries awaiting
review. As such, any library on the schedule can be reviewed once the
developer is ready, a review manager has been secured, and 
the manager, developer, and wizards agree on a date 
to schedule the review.

Review Schedule
===============

* Join (M)
* Sorting (M)
* Quaternions, Vectors, Matrices (M)
* Block Pointer (M)
* Singularity (M)
* Extended Complex Numbers (M)
* Metaparse (M)
* Boost.Range Extensions
* Nowide (M)
* Array (M)
* STL Extensions (M)
* Countertree (M)
* Process (M)
* Asynchronous File I/O (M)
* Application (M)
* Edit Distance (M)
* Mixin (M)
* Dependency Injection (M)
* DLL (M)

``(M)`` marks libraries that need review managers.

--------------------

Join
----
:Author: Yigong Liu

:Review Manager: Needed

:Download: http://channel.sourceforge.net/

:Description:
 Join is an asynchronous, message based C++ concurrency
 library based on join calculus. It is applicable both to
 multi-threaded applications and to the orchestration of asynchronous,
 event-based applications. It follows Comega's design and
 implementation and builds with Boost facilities. It provides a high
 level concurrency API with asynchronous methods, synchronous methods,
 and chords which are "join-patterns" defining the synchronization,
 asynchrony, and concurrency.

Sorting
-------
:Author: Steven Ross

:Review Manager: Needed

:Download: https://github.com/boost-vault/Sorting

:Description:
 A grouping of 3 templated hybrid radix/comparison-based sorting
 algorithms that provide superior worst-case and average-case
 performance to std::sort: integer_sort, which sorts fixed-size data
 types that support a rightshift (default of >>) and a comparison
 (default of <) operator.   float_sort, which sorts standard
 floating-point numbers by safely casting them to integers.
 string_sort, which sorts variable-length data types, and is optimized
 for 8-bit character strings.

 All 3 algorithms have O(n(k/s + s)) runtime where k is the number of
 bits in the data type and s is a constant, and limited memory overhead
 (in the kB for realistic inputs).   In testing, integer_sort varies
 from 35% faster to 2X as fast as std::sort, depending on processor,
 compiler optimizations, and data distribution.   float_sort is roughly
 70% faster than std::sort.   string_sort is roughly 2X
 as fast as std::sort.

Quaternions, Vectors, Matrices
------------------------------
:Author: Emil Dotchevski

:Review Manager: Needed

:Download: http://www.revergestudios.com/boost-qvm/

:Description:
 QVM defines a set of generic functions and operator overloads for
 working with quaternions, vectors and matrices of static size. The
 library also defines vector and matrix data types, however it allows
 users to introduce their own types by specializing the q_traits,
 v_traits and m_traits templates.

Block Pointer
-------------
:Author: Phil Bouchard

:Review Manager: Needed

:Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/

:Description:
 Deterministic memory manager of constant complexity capable of
 handling cyclic collections.

Singularity
-----------
:Author: Ben Robinson

:Review Manager: Needed

:Download: https://github.com/cppmaven/Singularity

:Description: The Singularity Design Pattern allows you to restrict
  any class to a single instance. Unlike the infamous Singleton,
  Singularity gives you direct control over the lifetime of the object,
  does not require you to grant global access to the object, nor does it
  limit you to the default constructor for that object.

Extended Complex Numbers
------------------------
:Author: Matthieu Schaller

:Review Manager: Needed

:Download: http://code.google.com/p/cpp-imaginary-numbers/

:Description:
 The library is an extension of the std::complex class addressing two issues:

 1.  The standard does not guaranty the behaviour of the complex class if 
     instantiated with types other than float/double/long double.

 2.  Some calculation where pure imaginary numbers (i.e. multiples of
     sqrt(-1)) appear are unnecessarily slowed down due to the lack of
     support for these numbers.  The code I submit contains two
     interleaved classes boost::complex and boost::imaginary which can
     be instantiated with any type T provided T overloads the usual
     arithmetic operators and some basic (real) mathematical functions
     depending on which complex function will be used.  It is thus an
     extended version of Thorsten Ottosen's n1869 proposal
     (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html)

Metaparse
---------
:Author: Abel Sinkovics

:Review Manager: Needed

:Download: http://abel.web.elte.hu/metaparse/metaparse.zip

:Description:

 Metaparse is a library for constructing parsers parsing at
 compile-time based on template metaprogramming. The parsers built with
 the library take boost::mpl::strings as input and can produce

 - types
 - objects (types with public static members)
 - callable C++ functions (types with public static method)
 - template metafunction classes

 as output (based on the input being parsed).

 On compilers supporting constexpr the library provides the following
 syntactic sugar for writing the input of the parsers:

 BOOST_STRING("this is a string")

 The library can be used for implementing DSLs in C++, including DSLs
 making C++ template metaprogramming easier (see examples).

Range Extensions
----------------
:Author: Akira Takahashi

:Review Manager: Neil Groves

:Download: https://github.com/faithandbrave/OvenToBoost

:Description:
 This project adds some features of the Oven Range Library to Boost.Range.
 Features:
 - Additional Range Adaptors (taken, taken_while, dropped,
 dropped_while, elements, elements_key, memoized, outdirected)
 - Extensions for using Lambda (regular function, regular operator)
 - Infinite Range (iteration function)
 - and additional range utilities.

Nowide
------
:Author: Artyom Beilis

:Review Manager: Needed

:Download: http://cppcms.com/files/nowide/

:Description:
 This library makes cross platform Unicode aware programming easier.
 It provides an implementation of standard C and C++ library functions,
 such that their inputs are UTF-8 aware on Windows without requiring to
 use Wide API.

Array
-----
:Author: Brian Smith

:Review Manager: Needed

:Download: https://github.com/BrianJSmith/Array

:Description:
 The array class is a C++11 compatible implementation of static
 multidimensional arrays.

STL Extensions
--------------
:Author: Vadim Stadnik

:Review Manager: Needed

:Download: https://github.com/vstadnik/stl_ext_adv_review

:Description:
 The proposed library [stl_ext_adv] offers augmented array based B+ trees 
 and STL containers that support the interfaces of the C++03 sequences 
 and associative containers. The library offers a number of extensions 
 and performance improvements that are not available in 
 C++03 and C++11 standard containers. 

Countertree
-----------
:Author: Francisco Jose Tapia

:Review Manager: Needed

:Download: https://dl.dropbox.com/u/8437476/works/countertree_code_doc.zip

:Description:
 This library is an implementation of a binary red-black counter tree. This
 tree have an additional counter in each leaf. This permit the access to the
 elements by the position, like in a vector. It is a random access container
 with random access iterators. 

 COUNTERTREE

 This kind of trees have an additional counter in each leaf. This
 permit the access to the elements by the position, like in a
 vector. It is a random access container with random access iterators.

 With unordered information we have a vector with the same speed
 inserting and deleting in any position (O(log N)).  With ordered
 information, we have the classes set, multiset, map and multimap, with
 identical interface than the STL classes, with the plus of access to
 the elements by position, like in a vector. The iterators are random
 access , and you can subtract them.

 SUBALLOCATOR

 The suballocator is a layer between the allocator and the data
 structures, compatible with any allocator with the STL definition. The
 suballocator replace to the allocator in the allocation of equal size
 elements. It provides speed, return the unused memory and decrease the
 memory used by the program and improve the cache performance due to
 the data locality improvement ( 30% of improvement of speed respect
 the std::allocator with GCC 4.7)

Process
-------
:Author: Boris Schaeling
:Review Manager: Needed
:Download: http://www.highscore.de/boost/process0.5/process.zip

:Description:
 Boost.Process is a library to manage system processes. It can be used to:

  * create child processes
  * setup streams for child processes
  * communicate with child processes through streams (synchronously or
    asynchronously)
  * wait for processes to exit (synchronously or asynchronously)
  * terminate processes

Asynchronous File I/O
---------------------
:Author: Niall Douglas and Paul Kirth
:Review Manager: Needed
:Download: https://github.com/BoostGSoC/boost.afio/archive/boost-peer-review.tar.gz

:Description: 
  Boost.AFIO is a linear scalable, batch, chainable,
  asynchronous closure execution engine with an almost wait free
  implementation extending Boost.ASIO and Boost.Thread specialised as a
  portable asynchronous file i/o implementation library. Implementation
  of this first version has been kept as simple as possible (~ 1000
  active LOC) at the cost of some performance, though with a good
  compiler you can expect 25-50% of the performance of using raw
  Boost.ASIO.

Application
-----------
:Author: Renato Tegon Forti
:Review Manager: Needed
:Download: https://github.com/retf/Boost.Application
:Documentation: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/index.html
:Description:
 Application provides an application environment, or start point
 to any people that want a basic infrastructure to build an system
 application on Windows or Unix Variants (e.g. Linux, MacOS).

 Application uses behaviours modeled using 'aspects' concept
 proposed by 'Vicente J. Botet Escriba', that allow easy extension and
 customization of library components. The application modes uses these
 components internally to achieve the user desirable behaviours.

 Application provide many useful ready-to-use features, e.g:

 * Run application as Windows Service;
 * Run application as UNIX/POSIX Daemon;
 * Plugin extension system;
 * Process(executable) Single instance Instantiation support;
 * Application SIGNAL/Callbacks customization;
 * Windows Service Setup feature;
 * And many others.

Edit Distance
-------------
:Author: Erik Erlandson
:Review Manager: Needed
:Download: https://github.com/erikerlandson/algorithm/tree/edit_distance/sequence
:Description:
  The edit distance is the length of the shortest (or least-cost) edit
  script from one sequence to another, where an edit script is defined
  as a sequence of insertion, deletion and (optionally) substitution
  operations.  The function implementing the edit distance is named
  edit_distance. This function will return the edit distance between two
  sequences, where sequences may be any valid range object supporting
  forward iteration.  The edit_distance function will also, if
  requested, return the edit script.

Mixin
-----
:Author: Borislav Stanimirov
:Download: https://github.com/iboB/boost.mixin
:Documentation: http://ibob.github.io/boost.mixin/
:Review Manager: Needed
:Description:
  Boost.Mixin is a library that allows the composition and
  modifications of polymorphic types at run time. Types and objects
  are constructed out of building blocks called mixins.

  The library uses the type boost::mixin::object as a placeholder,
  whose instances can be extended with existing classes (mixins), thus
  providing a particular instance with the functionality of all those
  types. Accessing the newly formed type's interface is made through
  messages:  stand-alone functions generated by the library, which can
  be thought of as methods.

  This is given while also having full abstraction between the
  interface and the definition of types.

  An existing feature in another language similar to Boost.Mixin and
  also an inspiration for the library are the mixins in Ruby. The
  library also has similarities with the pattern
  entity-component-system.

Dependency Injection
--------------------
:Author: 
:Download: https://github.com/krzysztof-jusiak/di
:Documentation: http://krzysztof-jusiak.github.io/di/boost/libs/di/doc/html
:Incubator: http://rrsd.com/blincubator.com/bi_library/di-dependency-injection/?gform_post_id=906
:Review Manager: Needed
:Description: 
  Boost.DI is a dependency injection library improving manual
  dependency injection by simplifying object instantiation with
  automatic dependencies injection. Using Boost.DI has many advantages
  over manual dependency injection.
  * Reduce boilerplate code (No factories, no objects creation in specific
    order)
  * Reduce cost of maintenance effort (Constructor signature change won't
    affect di configuration)
  * Reduce testing effort
  * Give better control of what and how is created (Policies, Providers)
  * Give better understanding about objects hierarchy (UML Dumper)

DLL
---
:Author: Antony Polukhin
:Download: https://github.com/apolukhin/Boost.DLL
:Documentation: http://apolukhin.github.io/Boost.DLL/index.html
:Review Manager: Needed
:Description: 
  This library was designed to simplify plugin development using C++
  in a portable cross-platform manner.

  Library provides a portable across platforms way to:
  * load libraries
  * import any native functions and variables
  * make alias names for C++ mangled functions and symbols
  * query libraries for sections and exported symbols
  * self loading and self querying
  * getting program and module location by exported symbol

Libraries under development
===========================

See The Boost Library Incubator Project at http://blincubator.com 
for discussion of libraries currently under development.

Niall Douglas | 12 Jan 16:51 2015

[gsoc15] Attn: We need 2015 mentors and project ideas for Boost!

Dear Boost community,

We are now within one month of the beginning of Google Summer of Code 
2015! Last year's GSoC furthered the continuing success of the Boost 
GSoC programme with the first ever Boost funded extension to a GSoC 
project (that being Boost.Hana by Louis Dionne mentored by Joel 
Falcou, congrats to both of them on passing an exceptionally tough 
selection process), and over $50,000 of Google funding brought to 
Boost in 2014. We also sent three representatives to last year's 
mentor summit, including one student whose entire expenses the Boost 
Steering Committee very generously covered.

As part of filling in our application for 2015, we must supply to 
Google a list of potential GSoC mentors and potential GSoC projects 
for summer 2015. There are a number of changes to how we design 
project ideas for students this year intended to improve the GSoC 
experience for both students and mentors, so please examine the ideas 
page which outlines those changes at 
https://svn.boost.org/trac/boost/wiki/SoC2015 and if you have any 
questions or concerns about those changes, please ask now rather than 
just before the GSoC deadline.

If you think yourself able to mentor a student doing some work on 
Boost this summer, *please* consider adding a description of the 
proposed work item and your name to the list. Last year we acquired 
eight slots from Google and had to disappoint two mentors and 
students, we hope with the improved selection process we can get back 
to the ten annual slots we once had.

If you want to know more about mentoring a Google Summer of Code 
funded
student work before you nominate yourself, please feel free to ask on 
the
main Boost developers mailing list boost <at> lists.boost.org. Thank you 
in
advance for your time.

Niall Douglas (Boost Google Summer of Code admin)
Boris Schäling (Boost Google Summer of Code admin)

--- 
Boost C++ Libraries Google Summer of Code 2014 admin
https://svn.boost.org/trac/boost/wiki/SoC2014

Attachment (SMime.p7s): application/x-pkcs7-signature, 8 KiB
Dear Boost community,

We are now within one month of the beginning of Google Summer of Code 
2015! Last year's GSoC furthered the continuing success of the Boost 
GSoC programme with the first ever Boost funded extension to a GSoC 
project (that being Boost.Hana by Louis Dionne mentored by Joel 
Falcou, congrats to both of them on passing an exceptionally tough 
selection process), and over $50,000 of Google funding brought to 
Boost in 2014. We also sent three representatives to last year's 
mentor summit, including one student whose entire expenses the Boost 
Steering Committee very generously covered.

As part of filling in our application for 2015, we must supply to 
Google a list of potential GSoC mentors and potential GSoC projects 
for summer 2015. There are a number of changes to how we design 
project ideas for students this year intended to improve the GSoC 
experience for both students and mentors, so please examine the ideas 
page which outlines those changes at 
https://svn.boost.org/trac/boost/wiki/SoC2015 and if you have any 
questions or concerns about those changes, please ask now rather than 
just before the GSoC deadline.

If you think yourself able to mentor a student doing some work on 
Boost this summer, *please* consider adding a description of the 
proposed work item and your name to the list. Last year we acquired 
eight slots from Google and had to disappoint two mentors and 
students, we hope with the improved selection process we can get back 
to the ten annual slots we once had.

If you want to know more about mentoring a Google Summer of Code 
funded
student work before you nominate yourself, please feel free to ask on 
the
main Boost developers mailing list boost <at> lists.boost.org. Thank you 
in
advance for your time.

Niall Douglas (Boost Google Summer of Code admin)
Boris Schäling (Boost Google Summer of Code admin)

--- 
Boost C++ Libraries Google Summer of Code 2014 admin
https://svn.boost.org/trac/boost/wiki/SoC2014

Antony Polukhin | 1 Jan 20:55 2015
Picon

[boost] [compute] Review results

Hi all,

Extended review period for Boost.Compute library has ended. Here are the review votes for inclusion (+ means include, - means do not include, +/- means conditional include or "probably include, not quite sure"):

+ Denis Demidov
+ Sebastian Schaetz
+ Pavan Yalamanchili
- Gruenke,Matt (+ if more backends will be supported)
+ Asbjørn (mini-review/comments from a library user)
+ Thomas M (a lot of suggestions)
+ Paul A. Bristow
+ Belcourt, Kenneth
+ John Bytheway
+/- Yiannis Papadopoulos (there's already Bolt/Thrust for beginner and pure OpenCL for pros)
+/- Vicente J. Botet Escriba (better docs and more performance tests)
+/- Jason Newton (there was no explicit answer to the question "shuld be this library accepted into Boost?" but the review was positive in general)


To sum up: Compute library becomes part of the Boost.

Great thanks to all for the reviews and comments! Huge work was done and the issues raised are essential for library success.


P.S.: Happy new year everyone!
P.P.S.: Hope I did not miss some review! In case of any error, please let me know!

--
Best regards,
Antony Polukhin
<div><div dir="ltr">
<div>Hi all,<br><br>
</div>Extended review period for Boost.Compute library has ended. Here are the review votes for inclusion (+ means include, - means do not include, +/- means conditional include or "probably include, not quite sure"):<br><div><div>
<div>
<br>+ <span name="Denis Demidov" class="">Denis Demidov</span><br>+ Sebastian Schaetz<br>+ <span name="Pavan Yalamanchili" class="">Pavan Yalamanchili<br></span>- Gruenke,Matt (+ if more backends will be supported)<br>+ <span name="Asbj&oslash;rn" class="">Asbj&oslash;rn (mini-</span><span name="Asbj&oslash;rn" class="">review/comments from a library user)</span><br>+ <span name="Thomas M" class="">Thomas M</span> (a lot of suggestions)<br>+<span name="Paul A. Bristow" class=""> Paul A. Bristow</span><br>+<span name="Belcourt, Kenneth" class=""> Belcourt, Kenneth</span><br>+<span name="John Bytheway" class=""> John Bytheway</span><br>+/-<span name="Yiannis Papadopoulos" class=""> Yiannis Papadopoulos</span> (there's already Bolt/Thrust for beginner and pure OpenCL for pros)<br>+<span name="Vicente J. Botet Escriba" class="">/- Vicente J. Botet Escriba</span> (better docs and more performance tests)<br>+<span name="Jason Newton" class="">/- Jason Newton</span> (there was no explicit answer to the question "shuld be this library accepted into Boost?" but the review was positive in general)<br><br><br>
</div>
<div>To sum up: Compute library becomes part of the Boost.<br><br>
</div>
<div>Great thanks to all for the reviews and comments! Huge work was done and the issues raised are essential for library success.<br>
</div>
<div><br></div>
<div><br></div>
<div>P.S.: Happy new year everyone!<br>
</div>
<div>P.P.S.: Hope I did not miss some review! In case of any error, please let me know!<br>
</div>
<div>
<br>-- <br><div class="gmail_signature">Best regards,<br>Antony Polukhin</div>
</div>
</div></div>
</div></div>
Antony Polukhin | 23 Dec 11:20 2014
Picon

[boost] [compute] Review period extended till December 30 + sum up

Hi,

Review period of Compute library extended till December 30.


Some notes and answers to them that were pointed out during review so far:

* Some of the algorithms could be tuned for a specific hardware
  - Library author is working on a auto-tuning solution and improves existing algos

* Why OpenCL C API used instead of C++ API?
  - C++ API had issues, C API allows a bit more control. No C++ API for OpenCL 2.0

* API is not N4105 compatible, library is not N*** compatible
  - This could be easily fixed by a library that will use Compute as a backend

* Some of the algorithms return futures while other work with command queues
  - This is because of the OpenCL design + async chains/futures would be probably added later

* Not all the types of the Khronos API are supported
  - A few types are not documented yet, there's a patch in the works which would allow the Khronos C++ types to be passed into Compute algorithms

* A few type related errors could be detected at compile time
  - This will be fixed, more asserts would be added to runtime only checkable places. Report issues to the tracker https://github.com/kylelutz/compute/issues

* On small data sets CPU algorithm would work faster than a GPGPU. How about implicitly dispatching algo on CPU in those cases?
  - The call on whether to execute the algorithm should be left up to the user. While library author agrees that this would be a useful feature, he just don't think Compute is the right place for that logic.

* How about providing way to do chains of async operations
  - This is a big task that will be solved some day.

* How about providing Boost.ASIO like error handling via throw and error_code
  - Implementing an approach like ASIO's wouldn't be that difficult.


Thanks to all the reviewers for spending their time and providing useful comments so far!

--
Best regards,
Antony Polukhin
<div><div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Hi,<br><br>Review period of Compute library extended till December 30.<br>
</div>
<br><br>Some notes and answers to them that were pointed out during review so far:<br><br>
</div>* Some of the algorithms could be tuned for a specific hardware<br>
</div>&nbsp; - Library author is working on a auto-tuning solution and improves existing algos<br><br>
</div>* Why OpenCL C API used instead of C++ API?<br>
</div>&nbsp; - C++ API had issues, C API allows a bit more control. No C++ API for OpenCL 2.0<br><br>* API is not N4105 compatible, library is not N*** compatible<br>
</div>&nbsp; - This could be easily fixed by a library that will use Compute as a backend<br>
</div>
<br>* Some of the algorithms return futures while other work with command queues<br>
</div>&nbsp; - This is because of the OpenCL design + async chains/futures would be probably added later<br>
</div>
<br>* Not all the types of the Khronos API are supported<br>
</div>&nbsp; - A few types are not documented yet, there's a patch in the works which would allow the Khronos C++ types to be passed into Compute algorithms<br>
</div>
<br>* A few type related errors could be detected at compile time<br>
</div>&nbsp; - This will be fixed, more asserts would be added to runtime only checkable places. Report issues to the tracker <a href="https://github.com/kylelutz/compute/issues">https://github.com/kylelutz/compute/issues</a><br><div><div><div><div><div><div><div><div><div><div><div><div><div>
<div>
<br>* On small data sets CPU algorithm would work faster than a GPGPU. How about implicitly dispatching algo on CPU in those cases?<br>&nbsp; - The call on whether to execute the algorithm should be left up to the user. While library author agrees that this would be a useful feature, he just
don't think Compute is the right place for that logic.<br>
</div>
<div>
<br>* How about providing way to do chains of async operations<br>
</div>
<div>&nbsp; - This is a big task that will be solved some day.<br>
</div>
<div>
<br>* How about providing Boost.ASIO like error handling via throw and error_code<br>
</div>
<div>&nbsp; - Implementing an approach like ASIO's wouldn't be that difficult.<br>
</div>
<div>
<br><br>
</div>
<div>Thanks to all the reviewers for spending their time and providing useful comments so far!<br><br>
</div>
<div>-- <br><div class="gmail_signature">Best regards,<br>Antony Polukhin</div>
</div>
</div></div></div></div></div></div></div></div></div></div></div></div></div>
</div></div>
Antony Polukhin | 15 Dec 07:57 2014
Picon

[boost] [compute] Review period starts today December 15, 2014, ends on December 24, 2014

Dear All,

Review of the Compute library starts today on Mon 25st of December 2014 and will last for ten days.


The Compute library provides a C++ interface to multi-core GPGPU and CPU computing platforms based on OpenCL.


The project is hosted on GitHub at https://github.com/kylelutz/compute.
Docs are available at http://kylelutz.github.io/compute/
Sources could be downloaded as a ZIP archive via https://github.com/kylelutz/compute/archive/master.zip
Some pre-official reviews could be found in Boost Library Incubator: http://rrsd.com/blincubator.com/reviews/?library_id=669


Please, answer the following questions in your review:

1. What is your evaluation of the design?

2. What is your evaluation of the implementation?

3. What is your evaluation of the documentation?

4. What is your evaluation of the potential usefulness of the
library?

5. Did you try to use the library? With what compiler? Did you have
any problems?

6. How much effort did you put into your evaluation? A glance? A
quick reading? In-depth study?

7. Are you knowledgeable about the problem domain?


And finally, every review should answer this question:

8. Do you think the library should be accepted as a Boost library? Be
sure to say this explicitly so that your other comments don't obscure
your overall opinion.


--
Best regards,
Antony Polukhin
<div><div dir="ltr">Dear All,<br clear="all"><div>
<br><span>Review</span> of the Compute library starts today on Mon 25st of December 2014 and will last for ten days.<br><br><br>The Compute library provides a C++ interface to multi-core GPGPU and CPU computing platforms based on OpenCL.<br><br><br>The project is hosted on GitHub at <a rel="nofollow" href="https://github.com/kylelutz/compute" dir="ltr" target="_blank">https://github.com/kylelutz/compute</a>.<br>Docs are available at <a rel="nofollow" href="http://kylelutz.github.io/compute/" dir="ltr" target="_blank">http://kylelutz.github.io/compute/</a><br>
</div>
<div>Sources could be downloaded as a ZIP archive via <a href="https://github.com/kylelutz/compute/archive/master.zip" target="_blank">https://github.com/kylelutz/compute/archive/master.zip</a><br>
</div>
<div>Some pre-official reviews could be found in Boost Library Incubator: <a href="http://rrsd.com/blincubator.com/reviews/?library_id=669" target="_blank">http://rrsd.com/blincubator.com/reviews/?library_id=669</a><br>
</div>
<div>
<br><br>
</div>
<div>Please, answer the following questions in your review:<br>
</div>
<div>
<br>
1. What is your evaluation of the design?<br><br>
2. What is your evaluation of the implementation?<br><br>
3. What is your evaluation of the documentation?<br><br>
4. What is your evaluation of the potential usefulness of the<br>
library?<br><br>
5. Did you try to use the library? With what compiler? Did you have<br>
any problems?<br><br>
6. How much effort did you put into your evaluation? A glance? A<br>
quick reading? In-depth study?<br><br>
7. Are you knowledgeable about the problem domain?<br><br><br>
And finally, every <span>review</span> should answer this question:<br><br>
8. Do you think the library should be accepted as a Boost library? Be<br>
sure to say this explicitly so that your other comments don't obscure<br>
your overall opinion.<br><br>
</div>
<div>
<br>-- <br><div>Best regards,<br>Antony Polukhin</div>
</div>
</div></div>
Edward Diener | 27 Nov 05:57 2014

[review] [sort] Sort library review manager results

This is the results from the recent review of the Sort library of Steven Ross.

First I would like to thank all those who made comments during the review, whether or not they officially gave a final Yes or No vote to whether the Sort library should be accepted as a Boost library. This list includes:

Niall Douglas, Julian Gonggrijp, Phil Endecott, Vladimir Prus, Mathias Gaunard, Jeremy Murphy, Peter Dimov, Robert Ramey, Adam Walling, Anthony Polukhin, Phil Endecott, Paul Bristow, Thijs (M.A.) van den Berg
Dupuis Etienne, and Frank Gennari

If I have missed anyone I do apologize.

Secondly I would like to thank Steven Ross for patiently answering all of the review comments to the best of his ability.

My tally of Yes and No votes for acceptance are:

Yes votes (5) :

Niall Douglas ( conditional ), Julian Gonggrijp ( conditional ),
Frank Gennari, Phil Endecott, Paul Bristow.

No votes (3) :

Vladimir Prus, Adam Walling ( conditional ), Anthony Polukhin

I believe the condtional Yes vote from Julian Gonggrijp was completely met in the discussions of issues with Steven Ross and the conditional Yes vote from Niall Douglas was almost completely met in the discussion with Steven Ross about the issues mentioned, and enough to maintain his Yes vote.

I want to also mention that the conditional No vote by Adam Walling has an implied Yes vote to it if the Sort library were one among other sort implementations.

Since my final decision is not entirely based on the Yes and No votes I want to adumbrate some of the major issues brought up by the review without necessarily focussing on every one of the people who brought them up initially, as well as my own reactions to them as Review Manager.

1) The first major issue was whether a library whose basic merit lies in its algorithm and its speed/space constraints needs better theoretical backing. A number of reviewers discussed this after it was brought up. I tend to agree with reviewers that while the best  theoretical basis is always desirable, it is not necessary for a Boost library whose empirical evidence can be and has been measured by its implementor and can be measured by any user. Furthermore Steven Ross has provided an extensive discussion in his documentation, as well as his original paper, about the theoretical merits of his technique. While much of this discussion is probably beyond the understanding of any but sorting experts and afficionados enough of it adequately explains the basic ideas behind SpreadSort for those who understand and have knowledge of basic sorting ideas and popular sorting techniques.

2) An important issue is the need for the Sorting library to provide extensive timing charts/tables comparing SpreadSort to at least std::sort ( and possibly other popular mainstream sorts ) with both different numbers of sort keys and different initial unsorted distributions. Steven Ross has been providing these charts/tables in the 'develop' branch of the library.

3) Connected to the previous issue is that a number of reviewers asked for better documentation on the conditions in which SpreadSort will show a marked improvement in speed compared to std::sort, as well as any condition(s) where SpreadSort performs worse than std::sort. While Steven Ross has explained that generally SpreadSort will fall back to using std::sort for some cases ( low N ), I too feel that the documentation needs to be more extensive for the average user in attempting to delineate the conditions where SpreadSort works best.

4) A really important issue discussed by a number of reviewers involves the creation of a synthetic radix, where most users of sorting algorithm are used to comparison based sorting functors. While the documentation provides information on the various individual sorts, as well as examples, I also feel that a discussion in the documentation of how to use SpreadSort when sorting structs/classes with multiple keys of different types would be invaluable. In other words, what and if are the common techniques for using SpreadSort with complicated keys which, when using comparison-based sorting, can be represented fairly easily be a functor.

5) Niall Douglas brought up the issue of exception guarantees when using SpreadSort, and I concur. The documentation should be stronger specifying what happens during the sorting algorithms if an exception occurs and/or does the sorting algorithm itself ever throw any exceptions and, if so, under what conditions. Steven Ross mentioned that he is adding exception guarantee information to his docs.

6) Many reviewers did not like the idea that the library should be called Sort when it is basically implementing a single sorting algorithm called SpreadSort. Alternate suggestions are:

a) The library should be called SpreadSort.
b) The library can be called Sort only if other sorting algorithms are added to it.
c) The library can be called Sort with the proviso that it serves as a general library for sorting algorithms potentially added to it in the future.
d) The library should be part of the Boost Algorithm library.

Steven Ross mentioned other potential sorting implementations as part of the Sort library, under that general name, but all providing a good deal of extra work. These included a copy-based stable sorting algorithm, an LSD radix sorting, and an OpenMP based parallel implementation. Other reviewers mentioned some of the same types of sorting implementations and a few reviewers remarked that they also have created sorting implementations of their own. While I will give my own view at the end, I would like to mention here that I strongly believe that each sorting implementation needs to be reviewed separately for acceptance into Boost and never automatically added to a general library, whether it be called Sort or Algorithm or whatever.

7) Random issues brought up in comments I will mention, which have importance but which I do not believe are absolutely intrinsic yet still might be considered.

a) C++11 techniques in general and inline namespaces in particular.
b) A version that can work with less than random access.
c) Optimizations for small sets of data ( Steven Ross has already addressed this to an extent in the 'developer' branch of the library ).
d) Possible documentation of using SpreadSort as a subsort for parallel sorting techniques and possible discusion in the docs about SpreadSort and parallel sorts.
e) General O() information in docs.
f) SpreadSort examples hoisted directly into docs using Quickbook technique and updating the Spreadort docs to use Quickbook.

Review Result:

Based on the voting for acceptance or not, based on the discussions during the review period, and based on Steven Ross's responses, I have decided that Steven Ross's library should be accepted into Boost.

My main reason for my decision, aside from the votes and comments and specific issues discussed, is twofold:

1) There is a general consensus that Steven Ross has an excellent understanding of sorting techniques and algorithms and will support and refine his library for the benefit of programmers.
2) The empirical tests show that SpreadSort offers an improvement over std::sort, significantly in the area of large data sets, and this could be a major benefit to programmers.

I do not know if the review manager has a say in this but based on the remarks of the reviewers I would like to see the library as accepted be named 'SpreadSort' rather than just 'Sort'. I do think that Boost can have a library called 'Sort' but I agree with the general consensus that a 'Sort' library needs more than one type of sorting algorithm. I would like to see other people, who mentioned in the reviews/comments that they have their own sorting implementation, also submit their own implementations to Boost and, if this happens and they are accepted, I can see combining them with 'SpreadSort' into a general Boost sorting library called 'Sort' in the future.
<div>
    <div class="moz-text-flowed" lang="x-western">This is the results from the
      recent review of the Sort library of Steven Ross.
      <br><br>
      First I would like to thank all those who made comments during the
      review, whether or not they officially gave a final Yes or No vote
      to whether the Sort library should be accepted as a Boost library.
      This list includes:
      <br><br>
      Niall Douglas, Julian Gonggrijp, Phil Endecott, Vladimir Prus,
      Mathias Gaunard, Jeremy Murphy, Peter Dimov, Robert Ramey, Adam
      Walling, Anthony Polukhin, Phil Endecott, Paul Bristow, Thijs
      (M.A.) van den Berg
      <br>
      Dupuis Etienne, and Frank Gennari
      <br><br>
      If I have missed anyone I do apologize.
      <br><br>
      Secondly I would like to thank Steven Ross for patiently answering
      all of the review comments to the best of his ability.
      <br><br>
      My tally of Yes and No votes for acceptance are:
      <br><br>
      Yes votes (5) :
      <br><br>
      Niall Douglas ( conditional ), Julian Gonggrijp ( conditional ),
      <br>
      Frank Gennari, Phil Endecott, Paul Bristow.
      <br><br>
      No votes (3) :
      <br><br>
      Vladimir Prus, Adam Walling ( conditional ), Anthony Polukhin
      <br><br>
      I believe the condtional Yes vote from Julian Gonggrijp was
      completely met in the discussions of issues with Steven Ross and
      the conditional Yes vote from Niall Douglas was almost completely
      met in the discussion with Steven Ross about the issues mentioned,
      and enough to maintain his Yes vote.
      <br><br>
      I want to also mention that the conditional No vote by Adam
      Walling has an implied Yes vote to it if the Sort library were one
      among other sort implementations.
      <br><br>
      Since my final decision is not entirely based on the Yes and No
      votes I want to adumbrate some of the major issues brought up by
      the review without necessarily focussing on every one of the
      people who brought them up initially, as well as my own reactions
      to them as Review Manager.
      <br><br>
      1) The first major issue was whether a library whose basic merit
      lies in its algorithm and its speed/space constraints needs better
      theoretical backing. A number of reviewers discussed this after it
      was brought up. I tend to agree with reviewers that while the
      best&nbsp; theoretical basis is always desirable, it is not necessary
      for a Boost library whose empirical evidence can be and has been
      measured by its implementor and can be measured by any user.
      Furthermore Steven Ross has provided an extensive discussion in
      his documentation, as well as his original paper, about the
      theoretical merits of his technique. While much of this discussion
      is probably beyond the understanding of any but sorting experts
      and afficionados enough of it adequately explains the basic ideas
      behind SpreadSort for those who understand and have knowledge of
      basic sorting ideas and popular sorting techniques.
      <br><br>
      2) An important issue is the need for the Sorting library to
      provide extensive timing charts/tables comparing SpreadSort to at
      least std::sort ( and possibly other popular mainstream sorts )
      with both different numbers of sort keys and different initial
      unsorted distributions. Steven Ross has been providing these
      charts/tables in the 'develop' branch of the library.
      <br><br>
      3) Connected to the previous issue is that a number of reviewers
      asked for better documentation on the conditions in which
      SpreadSort will show a marked improvement in speed compared to
      std::sort, as well as any condition(s) where SpreadSort performs
      worse than std::sort. While Steven Ross has explained that
      generally SpreadSort will fall back to using std::sort for some
      cases ( low N ), I too feel that the documentation needs to be
      more extensive for the average user in attempting to delineate the
      conditions where SpreadSort works best.
      <br><br>
      4) A really important issue discussed by a number of reviewers
      involves the creation of a synthetic radix, where most users of
      sorting algorithm are used to comparison based sorting functors.
      While the documentation provides information on the various
      individual sorts, as well as examples, I also feel that a
      discussion in the documentation of how to use SpreadSort when
      sorting structs/classes with multiple keys of different types
      would be invaluable. In other words, what and if are the common
      techniques for using SpreadSort with complicated keys which, when
      using comparison-based sorting, can be represented fairly easily
      be a functor.
      <br><br>
      5) Niall Douglas brought up the issue of exception guarantees when
      using SpreadSort, and I concur. The documentation should be
      stronger specifying what happens during the sorting algorithms if
      an exception occurs and/or does the sorting algorithm itself ever
      throw any exceptions and, if so, under what conditions. Steven
      Ross mentioned that he is adding exception guarantee information
      to his docs.
      <br><br>
      6) Many reviewers did not like the idea that the library should be
      called Sort when it is basically implementing a single sorting
      algorithm called SpreadSort. Alternate suggestions are:
      <br><br>
      a) The library should be called SpreadSort.
      <br>
      b) The library can be called Sort only if other sorting algorithms
      are added to it.
      <br>
      c) The library can be called Sort with the proviso that it serves
      as a general library for sorting algorithms potentially added to
      it in the future.
      <br>
      d) The library should be part of the Boost Algorithm library.
      <br><br>
      Steven Ross mentioned other potential sorting implementations as
      part of the Sort library, under that general name, but all
      providing a good deal of extra work. These included a copy-based
      stable sorting algorithm, an LSD radix sorting, and an OpenMP
      based parallel implementation. Other reviewers mentioned some of
      the same types of sorting implementations and a few reviewers
      remarked that they also have created sorting implementations of
      their own. While I will give my own view at the end, I would like
      to mention here that I strongly believe that each sorting
      implementation needs to be reviewed separately for acceptance into
      Boost and never automatically added to a general library, whether
      it be called Sort or Algorithm or whatever.
      <br><br>
      7) Random issues brought up in comments I will mention, which have
      importance but which I do not believe are absolutely intrinsic yet
      still might be considered.
      <br><br>
      a) C++11 techniques in general and inline namespaces in
      particular.
      <br>
      b) A version that can work with less than random access.
      <br>
      c) Optimizations for small sets of data ( Steven Ross has already
      addressed this to an extent in the 'developer' branch of the
      library ).
      <br>
      d) Possible documentation of using SpreadSort as a subsort for
      parallel sorting techniques and possible discusion in the docs
      about SpreadSort and parallel sorts.
      <br>
      e) General O() information in docs.
      <br>
      f) SpreadSort examples hoisted directly into docs using Quickbook
      technique and updating the Spreadort docs to use Quickbook.
      <br><br>
      Review Result:
      <br><br>
      Based on the voting for acceptance or not, based on the
      discussions during the review period, and based on Steven Ross's
      responses, I have decided that Steven Ross's library should be
      accepted into Boost.
      <br><br>
      My main reason for my decision, aside from the votes and comments
      and specific issues discussed, is twofold:
      <br><br>
      1) There is a general consensus that Steven Ross has an excellent
      understanding of sorting techniques and algorithms and will
      support and refine his library for the benefit of programmers.
      <br>
      2) The empirical tests show that SpreadSort offers an improvement
      over std::sort, significantly in the area of large data sets, and
      this could be a major benefit to programmers.
      <br><br>
      I do not know if the review manager has a say in this but based on
      the remarks of the reviewers I would like to see the library as
      accepted be named 'SpreadSort' rather than just 'Sort'. I do think
      that Boost can have a library called 'Sort' but I agree with the
      general consensus that a 'Sort' library needs more than one type
      of sorting algorithm. I would like to see other people, who
      mentioned in the reviews/comments that they have their own sorting
      implementation, also submit their own implementations to Boost
      and, if this happens and they are accepted, I can see combining
      them with 'SpreadSort' into a general Boost sorting library called
      'Sort' in the future.
      <br>
</div>
  </div>
Edward Diener | 10 Nov 06:39 2014

[review] Formal review period for Sort library begins today, November 10, and ends Wednesday, November 19

The formal review of the Sort library by Steven Ross starts today, November 10 and is scheduled to continue through November 19th.

About the Sort library
==================

The Sort library is a library which implements hybrid sorting algorithms
based on a Spreadsort ( http://en.wikipedia.org/wiki/Spreadsort ), of which the author of the library, Steven Ross, is the inventor.

The algorithm provides a sort that is faster than O(n*log(n)).

The library provides a generic implementation of high-speed sorting algorithms that outperform those in the C++ standard in both average and worst case performance. These algorithms only work on random access iterators. They are hybrids using both radix and comparison-based sorting, specialized to sorting common data types, such as integers, floats, and strings. These algorithms are encoded in a generic fashion and accept functors, enabling them to sort any object that can be processed like these basic data types.

Where to get it
===============

The library is available on github at
https://github.com/spreadsort/sort.

The library is in modular Boost format and can be cloned to
libs/sort under your local modular boost directory.

I have provided as the review manager online documentation at:

http://eldiener.github.io/sort

Review guidelines
=================

Reviews should be submitted to the developer list (boost <at> lists.boost.org), preferably with '[sort]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 'eldiener at tropicsoft dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list.

For your review you may wish to consider the following questions:

     - What is your evaluation of the design?
     - What is your evaluation of the implementation?
     - What is your evaluation of the documentation?
     - What is your evaluation of the potential usefulness of the
       library?
     - Did you try to use the library?  With what compiler?  Did you
       have any problems?
     - How much effort did you put into your evaluation? A glance? A
       quick reading? In-depth study?
     - Are you knowledgeable about the problem domain?

And finally, every review should attempt to answer this question:

     - Do you think the library should be accepted as a Boost library?

Be sure to say this explicitly so that your other comments don't
obscure your overall opinion.

Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome.

I encourage all programmers with an interest or knowledge of sorting algorithms to be part of the review or discussion of the Sort library as your time permits.
<div>
    <div class="moz-text-flowed" lang="x-unicode">The formal review of the Sort
      library by Steven Ross starts today, November 10 and is scheduled
      to continue through November 19th.
      <br><br>
      About the Sort library
      <br>
      ==================
      <br><br>
      The Sort library is a library which implements hybrid sorting
      algorithms
      <br>
      based on a Spreadsort ( <a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Spreadsort">http://en.wikipedia.org/wiki/Spreadsort</a>
      ), of which the author of the library, Steven Ross, is the
      inventor.
      <br><br>
      The algorithm provides a sort that is faster than O(n*log(n)).
      <br><br>
      The library provides a generic implementation of high-speed
      sorting algorithms that outperform those in the C++ standard in
      both average and worst case performance. These algorithms only
      work on random access iterators. They are hybrids using both radix
      and comparison-based sorting, specialized to sorting common data
      types, such as integers, floats, and strings. These algorithms are
      encoded in a generic fashion and accept functors, enabling them to
      sort any object that can be processed like these basic data types.
      <br><br>
      Where to get it
      <br>
      ===============
      <br><br>
      The library is available on github at
      <br><a class="moz-txt-link-freetext" href="https://github.com/spreadsort/sort">https://github.com/spreadsort/sort</a>.
      <br><br>
      The library is in modular Boost format and can be cloned to
      <br>
      libs/sort under your local modular boost directory.
      <br><br>
      I have provided as the review manager online documentation at:
      <br><br><a class="moz-txt-link-freetext" href="http://eldiener.github.io/sort">http://eldiener.github.io/sort</a>
      <br><br>
      Review guidelines
      <br>
      =================
      <br><br>
      Reviews should be submitted to the developer list (<a class="moz-txt-link-abbreviated" href="mailto:boost <at> lists.boost.org">boost <at> lists.boost.org</a>),
      preferably with '[sort]' in the subject. Or if you don't wish to
      for some reason or are not subscribed to the developer list you
      can send them privately to me at 'eldiener at tropicsoft dot com'.
      If so, please let me know whether or not you'd like your review to
      be forwarded to the list.
      <br><br>
      For your review you may wish to consider the following questions:
      <br><br>
      &nbsp;&nbsp;&nbsp;&nbsp; - What is your evaluation of the design?
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp; - What is your evaluation of the implementation?
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp; - What is your evaluation of the documentation?
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp; - What is your evaluation of the potential usefulness of the
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; library?
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp; - Did you try to use the library?&nbsp; With what compiler?&nbsp; Did
      you
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; have any problems?
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp; - How much effort did you put into your evaluation? A glance?
      A
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; quick reading? In-depth study?
      <br>
      &nbsp;&nbsp;&nbsp;&nbsp; - Are you knowledgeable about the problem domain?
      <br><br>
      And finally, every review should attempt to answer this question:
      <br><br>
      &nbsp;&nbsp;&nbsp;&nbsp; - Do you think the library should be accepted as a Boost
      library?
      <br><br>
      Be sure to say this explicitly so that your other comments don't
      <br>
      obscure your overall opinion.
      <br><br>
      Even if you do not wish to give a full review any technical
      comment regarding the library is welcome as part of the review
      period and will help me as the review manager decide whether the
      library should be accepted as a Boost library. Any questions about
      the use of the library are also welcome.
      <br><br>
      I encourage all programmers with an interest or knowledge of
      sorting algorithms to be part of the review or discussion of the
      Sort library as your time permits.
      <br>
</div>
  </div>
Marshall Clow | 3 Nov 22:57 2014
Picon

Boost 1.57.0 has been released

Release 1.57.0 of the Boost C++ Libraries is now available.

These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. 
The Boost license encourages both commercial and non-commercial use.

This release contains no new libraries and numerous enhancements and bug fixes for existing libraries.

For details, including download links, see http://www.boost.org/users/news/version_1.57.0

You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.57.0/

To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html

Thanks,

--The Boost release team

  Vladimir Prus
  Rene Rivera
  Marshall Clow
  Eric Niebler
  Daniel James
  Beman Dawes
<div>
<div>Release 1.57.0 of the Boost C++ Libraries is now available.<br><br>These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications.&nbsp;<br>The Boost license encourages both commercial and non-commercial use.<br><br>This release contains no new libraries and numerous enhancements and bug fixes for existing libraries.<br><br>
</div>
<div>For details, including download links, see&nbsp;<a href="http://www.boost.org/users/news/version_1.57.0">http://www.boost.org/users/news/version_1.57.0</a><br><br>You can also download directly from SourceForge:&nbsp;<a href="http://sourceforge.net/projects/boost/files/boost/1.57.0/">http://sourceforge.net/projects/boost/files/boost/1.57.0/</a><br><br>To install this release on your system, see&nbsp;<a href="http://www.boost.org/doc/libs/release/more/getting_started/index.html">http://www.boost.org/doc/libs/release/more/getting_started/index.html</a><br><br>Thanks,<br><br>--The Boost release team<br><br>&nbsp;&nbsp;Vladimir Prus<br>&nbsp;&nbsp;Rene Rivera<br>&nbsp;&nbsp;Marshall Clow<br>&nbsp;&nbsp;Eric Niebler<br>&nbsp;&nbsp;Daniel James<br>&nbsp;&nbsp;Beman Dawes</div>
</div>
Niall Douglas | 3 Nov 13:02 2014

[gci2014] Calling for Google Code In 2014 tasks and mentors

Dear Boost,

Google Code In 2014 is nearly upon us, and we need bite sized tasks 
and mentors! Google Code In lasts between December and mid-January 
and is for 13 to 17 year olds to get involved with open source 
projects. Tasks need to be very short, maybe only three hours or so, 
but correspondingly the effort required to mentor/check these is very 
low. If you maintain a Boost library and could do with help in fixing 
up any of those items you keep putting off like replicating bug 
reports, fixing documentation errors, or configuring Continuous 
Integration, now is the time!

More information is on the GCI ideas page at:

https://svn.boost.org/trac/boost/wiki/gci2014

... where you can add more tasks and also sign yourself up as a 
mentor.

We need this page ready by Saturday 8th November, so please try to 
get it done before then. Thanks in advance!

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/

Attachment (SMime.p7s): application/x-pkcs7-signature, 8 KiB
Dear Boost,

Google Code In 2014 is nearly upon us, and we need bite sized tasks 
and mentors! Google Code In lasts between December and mid-January 
and is for 13 to 17 year olds to get involved with open source 
projects. Tasks need to be very short, maybe only three hours or so, 
but correspondingly the effort required to mentor/check these is very 
low. If you maintain a Boost library and could do with help in fixing 
up any of those items you keep putting off like replicating bug 
reports, fixing documentation errors, or configuring Continuous 
Integration, now is the time!

More information is on the GCI ideas page at:

https://svn.boost.org/trac/boost/wiki/gci2014

... where you can add more tasks and also sign yourself up as a 
mentor.

We need this page ready by Saturday 8th November, so please try to 
get it done before then. Thanks in advance!

Niall

--

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/


Gmane