Re: [boost] [GSOC] Are we going to participate?

Subject: Re: [boost] [GSOC] Are we going to participate?
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2013-02-17 18:24:36

> Antony Polukhin wrote:
> > 2013/2/14 Michael Marcin <mike.marcin_at_[hidden]>:
> >> Boris Schaeling wrote:
> >>> For now no idea is too stupid - and even if it is, it might help
> >>> someone else to get a good idea. :)
> >
> > More ideas:
> > - USB library (integrated with asio?)
> > - COM port library (integrated with asio?)
> > - Hardware random number generator (integate with Boost.Random!)
> > - Pipes and named pipes library (integrated with asio? integrated with
> > IOstreams?)
> > - Protocols implementation based on asio (SNMP for example )
> > - Simple key-value reading and storing (or just allow program options
> > to write options into config file)
> > - Full text search
> > - Near Duplicate Detection (shingling)
> >
> 
> Antony Polukhin wrote:> 2013/2/14 Michael Marcin <mike.marcin_at_[hidden]>:
>  >> Boris Schaeling wrote:
>  >>> For now no idea is too stupid - and even if it is, it might help
> someone  >>> else to get a good idea. :)  >  > More ideas:
>  > - USB library (integrated with asio?)  > - COM port library (integrated
> with asio?)  > - Hardware random number generator (integate with
> Boost.Random!)  > - Pipes and named pipes library (integrated with asio?
> integrated with  > IOstreams?)  > - Protocols implementation based on asio
> (SNMP for example )  > - Simple key-value reading and storing (or just
> allow program options  > to write options into config file)  > - Full text
> search  > - Near Duplicate Detection (shingling)  >  >> We don't have to
> volunteer to implement any of these ideas right? :)  >  > Let's be honest,
> this ideas require much more than 3 months of coding:
>  >
>  >> - Hardware graphics (OpenGL/OpenGL|ES/DirectX abstraction)  >> - GUI
> library  >> - physics library (ODE/Havok/PhysX/etc abstraction)  >  > This
> is already implemented in Boost.PropertyTree (and there is a  > Spirit
> implementation in Spirits examples)  >> - json parsing libary  >  > Those
> I'd really love to heave:
>  >> - trie data structure
>  >> - radix sort
>  >
> 
> Some more:
> 
> - boost.flyweight value factories ( http://tinyurl.com/bktkc3s )
> - concurrent containers (unordered_map, unordered_set, vector,
> forward_list)
> - parallel algorithms (sort, for_each)
> - type switch library ( http://tinyurl.com/n3449 )
> - slim string (as opposed to the fat std::string interface, maybe
> immutable, maybe policy based, I seem to recall something like a
> flex_string)
> - rpc library

FWIW, something like this is already part of the HPX library
(https://github.com/STEllAR-GROUP/hpx). It integrates the rpc part nicely
with local thread scheduling and an actor based execution model.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu

> - benchmark framework (don't know if it's possible but something to help
> write reliable and good benchmarks that is as easy to use as the unit test
> framework, maybe output svg charts using the old gsoc visualization
> libary)
> - algorithms for gpgpu
> - video processing library (gil for video)
> - kinetic scrolling
> - cpuid
> - channel library ( http://channel.sourceforge.net/ )
> 
> 
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost