I can allocate a page on the Wiki for project ideas.

I've stubbed out a page for project ideas if any maintainers, library maintainers or contributors want to submit them. It's here: https://svn.boost.org/trac/boost/wiki/SoC2010 Andrew Sutton andrew.n.sutton@gmail.com

Thanks for starting this? matbe we can add a link to the preceding ideas ( http://svn.boost.org/trac/boost/wiki/SoCPrevious)

Done.

Do you know if we have a page of the preceding *accepted* projects and its status? It would be interesting to analyze the impact of SOC on Boost.

I can create a list from accepted projects last year from the SoC data. I'll do that later today. It's hard to guage the impact of SoC on Boost since it can be kind of hard getting code into trunk. I think that it might be easier to measure how many previous SoC students are now regular collaborators. Andrew Sutton andrew.n.sutton@gmail.com

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrew Sutton Sent: Sunday, March 07, 2010 3:02 PM To: boost@lists.boost.org Subject: Re: [boost] Summer of Code 2010

...

Do you know if we have a page of the preceding *accepted* projects and its status? It would be interesting to analyze the impact of SOC on Boost.

I can create a list from accepted projects last year from the SoC data. I'll do that later today.

It's hard to gauge the impact of SoC on Boost since it can be kind of hard getting code into trunk. I think that it might be easier to measure how many previous SoC students are now regular collaborators.

How about a list of projects that are probably still be in use, if not reviewed? Or a list of unfinished Boost projects that are promising but require more work to get into a finished and reviewable state? There are quite a lot of the latte. Often they just require tidying or refining and documenting but the original author has lost steam/interest/time - doing stupid things like getting jobs and babies! Although less exciting than to break new ground, the chance of ending up with an accepted library is *much* higher - if you stand on the shoulders of giants ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com

I'll try to spend the next couple of hours compiling that information. I'll see if I can't find out the status of past projects..

That was a tedious several hours... I've gone thru and collected all of the accepted projects and posted links to their proposals. It looks like we are not doing a very good job keeping up with past SoC work :) but the results are encouraging (I think, given the nature of Boost). There have been 33 accepted proposals in 4 years of participation (2006-2009). As far as I can tell 7 were not completed (21%). The program success rate last year was 15%, so we're lagging a little. The number of slots allocated to Boost has been declining each year. From 2006 to 2009 we had 9, 9, 8, and 7 slots to fund students. This is not a particularly good trend, but that number seems to depend on the number and quality of ideas and the availability of mentors. As far as I can see, only one SoC project has been accepted as an entirely new library: Boost.Bimap. There have been a handful of projects that resulted in extensions to existing libraries (2 for Boost.Graph, 2 for Boost.Math, I think). There are probably another 3 that need to be shepherded into existing projects, if they haven't already been done so (YAML, relation types, graph partitioning, others?). Others may have influenced the design or evolution of existing libraries, but this impact is hard to measure. Many of the libraries may be viable (I've labeled them as "viable" on trac) as independent libraries. I'm not sure about the status of some, but they seemed relatively complete and may be publishable. Some may even have users. They are: 2006 - Process, Coroutine, Concurrency* 2007 - CGI, Dataflow, Visualization, Extension/Reflection 2008 - ??? 2009 - ??? I actually can't measure the impact of the last 2 years on Boost. 2008 seems to have been a little more on the experimental side, and 2009... it might just be too soon to tell. I'm confident that at least 4 projects from 2009 will be integrated into existing Boost libraries, and I have high hopes for the unicode work. There are a number of projects that have been worked on or proposed a number of times. BigInt is the poster-child of these submissions, tries are common, trees, hypergraphs, C++0x upgrades... 3 projects targetted bigint and tries. None seems to have been particularly successful. I would guess that about 50% of completed projects will eventually (with 2 years?) have a directly measurable impact on Boost. That seems pretty low, but I'm not sure how to compare it against the "adoption rate" of other SoC projects. It would be nice to a number closer to 70% within 1 year, but I see two impediments. First, it's tough for students to get up to speed with Boost and meet the exacting requirements of reviewers. Second, but the time the students are really up to speed, it's back to school and the work basically stop. One way to improve those numbers is to develop a set of goal projects with precisely specified requirements... We want to have this data structure, that implements these operations, and no, you can't use libgmp. These projects should define a clear path to acceptance (testing, docs, formal review, etc.). That's all I've got for now. We need to start building a body of possible projects. It's one of the criteria by which organizations are selected. That reminds me... I suppose I should file a proposal tomorrow. If anybody who worked on a project as a student or mentor and has

information about it or its status, please let me know.

Still a valid request :) Andrew Sutton andrew.n.sutton@gmail.com

Concerning Unicode, I did the foolish choice this year of working full-time as the same time as I finish my studies, which hasn't left me as much free time as I would have liked it to. I will be resuming work on it this summer, however, as I am quite keen on getting it into Boost.

Working and studying seems to be increasingly common these days. Speaking from experience, it's absolutely killing my ability to get any quality work out of the undergrads in my department :) Are you planning to re-apply for SoC for this? If you did, how would the proposal vary from last year?

One concern I have is that it is quite close to Boost.Iterator, Boost.Range, Boost.RangeEx and Boost.StringAlgo, and I would like my changes to be added as improvement upon those libraries if possible. But I guess proposing everything under Boost.Unicode makes it quite easier to review and all.

I think that largely depends on the maintainer(s) of those libraries. I would hope that you could avoid a formal review since the libraries are already in place. I would also think that if the algo/iter/range changes are orthogonal to the unicode stuff, a separate review would be required. In the worst case, you could probably just wrap and hide the modified libraries. Andrew Sutton andrew.n.sutton@gmail.com

I agree (with whatever point you were trying to make.) The concern of what you call "dataflow iterator adapter" is definitely quite separated from specific codepoint or encoding concerns. /David NOTE: yes, I top posted here sorry. Typed on an iPhone On Mar 7, 2010, at 4:59 PM, "Robert Ramey" <ramey@rrsd.com> wrote:

Andrew Sutton wrote:

...

...

Concerning Unicode, I did the foolish choice this year of working full-time as the same time as I finish my studies, which hasn't left me as much free time as I would have liked it to. I will be resuming work on it this summer, however, as I am quite keen on getting it into Boost.

...

...

One concern I have is that it is quite close to Boost.Iterator, Boost.Range, Boost.RangeEx and Boost.StringAlgo, and I would like my changes to be added as improvement upon those libraries if possible. But I guess proposing everything under Boost.Unicode makes it quite easier to review and all.

Here is some information which may or may not be relevant here.

a) A number of years ago, I needed a codecvt facet to output UTF-8. I found one written by our own Ron Garcia. I checked it in as part of the seriailization library. It's been hassle free for all this time. I believe that others have used it as well.

b) As I recall, the original code also included the above conversion as an iterator - I don't see that code around any more.

c) Also as part of the library I needed a bunch of converters (multi-byte <-> unicode, etc) which needed to be composed with a bunch of other filters (base64, etc.). I made "dataflow iterators" which use just the addition of templated constructors to the boost iterators. All this has worked well as large part of the implementation occurs at compile time.

d) In the meantime boost.iostreams got made which also included some of this facility. This code isn't part of the codecvt facet machinery - which is where I would think it should be.

Soooooo - from my perspective, I would like to see.

a) templated constructors added to boost.iterators b) a bunch of iterator adaptors - some of which are like "dataflow iterators". c) a class for construction a codecvt facet out any iterator adaptor.

Previous efforts at a unicode library have seemed to bog down in codepoints and whole lot of other stuff I don't understand.

I don't know that I have a real point here. But for a long time it has seemed to be a lost opportunity to unify a bunch of stuff which seems to be re-invented all the time.

Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Andrew Sutton wrote:

Are you planning to re-apply for SoC for this? If you did, how would the proposal vary from last year?

No, I'm going to do it for free ;). I wouldn't be able to commit full-time anyway.

Hi Andrew, Thanks for taking this on! On 7 March 2010 20:25, Andrew Sutton <andrew.n.sutton@gmail.com> wrote:

It looks like we are not doing a very good job keeping up with past SoC work :) but the results are encouraging (I think, given the nature of Boost).

I have kept an eye on the past projects by means of the Boost SVN: https://svn.boost.org/trac/boost/browser/sandbox/SOC Just from the activity there, it's hard to tell where any of the projects are actually up to. Given the perfectionist nature of Boost, it's not always easy for the people involved to know exactly where the projects are up to either... ;) At a minimum, it would be good if there was an "official" round-up of each SoC a couple of months after the pens-down date. The number of slots allocated to Boost has been declining each year. From

2006 to 2009 we had 9, 9, 8, and 7 slots to fund students. This is not a particularly good trend, but that number seems to depend on the number and quality of ideas and the availability of mentors.

... add to that the success rate of previous years?

<snip>

First, it's tough for students to get up to speed with Boost and meet the exacting requirements of reviewers. Second, [by] the time the students are really up to speed, it's back to school and the work basically stop.

Accurate observation. The SoC is not very long at all and if it takes a student a week or two to get up to speed with Boost.Test, SVN and Boost.Build, that is a big chunk of time lost right at the start of the project. Students also tend to do crazy things like go away on holiday or have relatives come to stay, so the projects really need to be tight if they are going to succeed. I think it would help if there was a rule about having to commit something to svn each week. Students may be tentative about publicly displaying incomplete code but it's almost impossible to gauge how things are going otherwise. One way to improve those numbers is to develop a set of goal projects with

precisely specified requirements... We want to have this data structure, that implements these operations, and no, you can't use libgmp. These projects should define a clear path to acceptance (testing, docs, formal review, etc.).

If students were encouraged to write tests at the start of the SoC with their mentor, they would have a specific set of goals to work to. Mentors should be well placed to help the students define the precise requirements of the project. The path to acceptance from there is: get all the tests passing and document how the library does it. Even if this doesn't happen by the end of the SoC, there is still a definite goal.

If anybody who worked on a project as a student or mentor and has

...

information about it or its status, please let me know.

Still a valid request :)

Just chiming in with a brief status update of the CGI library: it is in working order and the interface is largely stable now. It needs some more housekeeping and a more complete test suite before it is ready for review and there is some internal refactoring I'd like to do to support more advanced uses. Support for sessions is included (finally) and I've been rewriting the documentation over the last couple of weeks as there has been significant changes since last year's (ultimately unsuccessful) SoC project. I had been planning on posting to the vault when that's ready. Cheers, Darren

Weekly releases should be mandatory for GSoC participants. I worked on Boost.Visualization during GSoC 2007, and they helped me accomplish most of my stated goals. Each week, I sent a list of promises to my Mentor, and worked like crazy to get them all finished and checked in by Sunday. He sent me nudges when I slipped a day, and I kept to the schedule I set out at the beginning of the summer. By releasing code each week, I noticed some of the bad decisions I made, and made two major reorganizations by the end of the summer. The end result was still poorly factored, but without weekly tasks it would have been poorly factored and incomplete!

Were you generating full releases each weak? I can certainly see how that policy can be used to measure progress. That's actually a good idea since it forces the student to think about end product as much as the code.

Please consider exceptions to this rule :).

There always are :) Andrew Sutton andrew.n.sutton@gmail.com

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jake Voytko Sent: Monday, March 08, 2010 4:20 PM To: boost@lists.boost.org Subject: Re: [boost] Summer of Code 2010

On Mon, Mar 8, 2010 at 8:15 AM, Andrew Sutton <andrew.n.sutton@gmail.com> wrote:

...

Were you generating full releases each weak? I can certainly see how that policy can be used to measure progress. That's actually a good idea since it forces the student to think about end product as much as the code.

Yes. There were exceptions: sometimes the documentation lagged behind, but overall the project advanced in lock-step once a week.

Yes - it did! And Jake got the documentation working at an early stage. We could use a Quickbook template to get GSoC people off the ground immediately, even before they write any C++. In retrospect it would have been even better to document the source using Doxygen as it was written. This was a massively tedious job afterwards :-( The reference section produced by Doxygen for Quickbook saves a lot of tedious work, and most important, is updated as the code changes. So I would say that not only the C++ stuff but the docs should be uploaded very often - each time some section is working at all, and probably more frequently than weekly. Warts and all! Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com

Andrew Sutton a écrit :

I'm a big fan of Doxygen + Quickbook :) Is there a template floating around that we give to students that will work once they're properly set up their environments?

The thing is that, normally, to build a sandbox project you're supposed to copy it into a boost checkout to have the jamfiles etc. I personally did not find that very practical and tried to do some standalone building based on BOOST_ROOT.

Hi there, On Mon, Mar 8, 2010 at 1:27 PM, Daniel James <dnljms@gmail.com> wrote:

On 8 March 2010 17:52, Andrew Sutton <andrew.n.sutton@gmail.com> wrote:

...

 I'm a big fan of Doxygen + Quickbook :) Is there a template floating around that we give to students that will work once they're properly set up their environments?

https://svn.boost.org/svn/boost/sandbox/example/

Feel free to make changes.

I think it's good enough as a starting point. What I would like to see is a step by step way of installing the quickbook toolset chain to compile the docs into html or pdf. I never got it to work on my machine. I have read the boost quickdoc documentation but it's not really straigh forward. Thanks, Christian

Christian Henning wrote:

...

I think it's good enough as a starting point. What I would like to see is a step by step way of installing the quickbook toolset chain to compile the docs into html or pdf. I never got it to work on my machine. I have read the boost quickdoc documentation but it's not really straigh forward.

I think I'd like that too. It seems like every time I update to work on docs, something has changed that breaks my previous setup. Have you read https://svn.boost.org/trac/boost/wiki/BoostDocs/GettingStarted

?

Not in a long time. Thanks for the reference. Andrew Sutton andrew.n.sutton@gmail.com

On 8 March 2010 21:18, Andrew Sutton <andrew.n.sutton@gmail.com> wrote:

...

Christian Henning wrote:

...

What I would like to see is a step by step way of installing the quickbook toolset chain to compile the docs into html or pdf. I never got it to work on my machine. I have read the boost quickdoc documentation but it's not really straigh forward.

It seems like every time I update to work on docs, something has changed that breaks my previous setup.

Have you read https://svn.boost.org/trac/boost/wiki/BoostDocs/GettingStarted?

setup_boostbook.py (in tools/boostbook) has worked for me. It downloads and sets up the various bits in the toolchain and updates your user-config.jam. I've had problems with it a couple of times but IIRC last time I tried it worked without a hitch. Cheers, Darren

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel James Sent: Monday, March 08, 2010 6:27 PM To: boost@lists.boost.org Subject: Re: [boost] Summer of Code 2010

On 8 March 2010 17:52, Andrew Sutton <andrew.n.sutton@gmail.com> wrote:

...

 I'm a big fan of Doxygen + Quickbook :) Is there a template floating around that we give to students that will work once they're properly set up their environments?

https://svn.boost.org/svn/boost/sandbox/example/

This is fine - as far as it goes - but it could use a lot of comments to explain to the non-cognoscenti what is going on. (It's written in the Outer Mongolian of computer languages don't forget!) But it's very far from the Full Monty with all the tricks of the trade (black arts!) to get the benefit from the full Doxygen and code snippets (not to mention indexing - pioneered by John Maddock but not quite working well yet). I've been working intermittently on a much fuller example, but keep getting distracted. (And every time I alter something it goes wrong :-( Making the documentation process slicker could be a GSoC project? Perhaps improving the documentation for some existing Boost libraries (s) en route might be good too. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com

...

Making the documentation process slicker could be a GSoC project? Perhaps improving the documentation for some existing Boost libraries (s) en route might be good too.

This kind of thing might be better done outside of boost, our tools tend to be too focused on our own needs. For example, one of clang's open projects is to implement a code documentation tool.

Yes, and now Clang has Python bindings to make that easier. I wonder who wrote those? ;) We can't actually accept proposals to work on documentation, since it's Summer of /Code/. This came up a couple of times on Google's extremely high traffic, high annoyance mentor mailing list last year. Actually, writing Doxygen for Clang would be a /great/ project, but I don't think we could mentor it. Could we? Plus, I don't think Clang is quite stable enough in the areas where we need it to be stable. It's pretty close, though. Andrew Sutton andrew.n.sutton@gmail.com

On Tue, Mar 9, 2010 at 9:23 AM, Marshall Clow <mclow.lists@gmail.com> wrote:

On Mar 9, 2010, at 5:20 AM, Andrew Sutton wrote:

...

We can't actually accept proposals to work on documentation, since it's Summer of /Code/. This came up a couple of times on Google's extremely high traffic, high annoyance mentor mailing list last year.

Actually, writing Doxygen for Clang would be a /great/ project, but I don't think we could mentor it. Could we? Plus, I don't think Clang is quite stable enough in the areas where we need it to be stable. It's pretty close, though.

I agree that this would be a great project.

I suppose, if one were to submit an application to develop a Clang-based Doxygen specifically for the Boost.Build tool chain, but with options to generalize, that could technically be within our domain :) Andrew Sutton andrew.n.sutton@gmail.com

I suppose, if one were to submit an application to develop a Clang-based

...

Doxygen specifically for the Boost.Build tool chain, but with options to generalize, that could technically be within our domain :)

Don't you think boost's domain is already enough spread out ? I think a little more focus would do the boost project a lot of good.

Probably a good point. I'll withdraw the suggestion. Andrew Sutton andrew.n.sutton@gmail.com

Andrew Sutton wrote:

...

The reference section produced by Doxygen for Quickbook saves a lot of tedious work, and most important, is updated as the code changes.

So I would say that not only the C++ stuff but the docs should be uploaded very often - each time some section is working at all, and probably more frequently than weekly. Warts and all!

I'm a big fan of Doxygen + Quickbook :) Is there a template floating around that we give to students that will work once they're properly set up their environments?

I would not say a template, but I found Boost.Asio docs as the best example of integration of Doxygen with Boostbook + Quickbook. It is fairly complex and uses XSL(T) but gives very good results, IMHO. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

Andrew Sutton wrote:

...

Google Summer of Code will continue in 2010, and I believe the organization

...

applications will be accepted starting March 8. Are we going to participate, and if so, who is taking responsibility for submitting the application?

Vladimir, Andrew,

this is just a little note to make sure you two are aware of each other and can plan together on how to move forward for this year's GSoC. I haven't been reading very carefully the boost lists these days, so I may have missed some messages. But since this generic call for action remained unanswered, I figured I better reply...

Hi Stefan, Vladimir

We should definitely move forward with this since organization submissions start in two days. I would be more than happy to submit an application. Who was responsible for submitting the application last year? Is there a previous version of the application that we can update and resubmit? The previous applications don't seem to be accessible from the SoC webapp. If there's not one available by Monday, I'll just write up a new one.

For avoidance of doubt -- was the application written and submitted? Deadline is tomorrow, I belive. - Volodya