[boost] [gsoc16] Re: Potential contribution scenarios?

Subject: [boost] [gsoc16] Re: Potential contribution scenarios?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2016-01-04 06:18:35

On 3 Jan 2016 at 22:19, Miguel Coimbra wrote:

> Two ideas of GSoC2015 in particular caught my attention:
> 
> - Concurrent Hash Tables - Mentor: Niall Douglas
> - Boost Document Library development - Mentor: Antony Polukhin
> 
> I have been looking for direct contacts to learn about some of these ideas
> (Niall Douglas and Antony Polukhin, respectively) from 2015's Google Summer
> of Code to find out more, but was unsuccessful so far.

It is not hard to find either myself or Antony. Both of us are here, 
and both of us are at the top of Google search results for our names.

> While the first idea was not put into practice, the second one was
> undertaken (by Anurag Ghosh if I am not mistaken).

Correct.

> Would anyone be able to point me in a direction to learn more about the
> state of work on these two ideas (specially the Document Library) and (if
> possible) if they are available for me to pick up and look into ways of
> contributing? Perhaps querying the mentors of those ideas for feedback?

I'm sure Antony will reply later about Boost.Document.

Regarding any project ideas based on concurrent hash tables or AFIO 
on past GSoC ideas pages, I will not be available as mentor for 
either topic in 2016.

The concurrent hash tables idea is still an excellent addition for 
Boost and may find a willing mentor somewhere here.

Anything related to AFIO is obsolete as the post-peer-review AFIO v2 
rewrite is a radically different design totally incommensurate with 
the AFIO which was peer reviewed, and any code contributed to AFIO v1 
would be a waste of effort as the v2 design doesn't allow code reuse 
from v1.

Hope that helps, and keep searching! Remember there are many more 
project ideas in even older GSoC ideas pages.

Some project ideas do spring to mind which I will add eventually to 
the GSoC 2016 ideas page:

1. A thing Boost really could do with is a decent (optionally 
mmappable) dense hash map implementation, so the hash map could 
contain billions of items and mostly reside on disk yet lookups would 
still be very fast.

2. Another is a constexpr compile time generated static map. Every 
Boost programmer here has at some time or other instantiated a global 
std::map or std::unordered_map populated from static data on process 
init and it would be really great now we have C++ 14 to get the 
compiler to do the map population at compile time such that you have 
a ready to go STL compliant map at process init.

I could be persuaded to mentor either proposal if the student were an 
outstanding C++ programmer with a proven record of writing very well 
tested solid code. Experience in unit testing is absolutely key here.

Niall

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