Giovanni Piero Deretta wrote:

...

Conduct student-mentor exclusively through public channels

This would also be great. While our mentors have been very helpful, more comments on our problems would have been useful. I would mandate that all *technical* communications should be public.

I have to say I think this is not at all a good idea. In development of a "speculative" idea, there are lots of failed experiments. Doing this in public would only consume lots of time and distract from job at hand. I think a better approach would be for software developers (us included) to keep a log of what we've been doing. This would include a record of the failed approaches that had been tried and discarded. This would eventually form the basis of the "rationale" and be very handy when a project is submited for review (formal or otherwise). Personally, I think the idea of software development as a collaborative activity is overrated. I see it as more personal. Of course criticism (constructive and otherwise) is a public activity. So I think those public dissicussions which speculate on how libraries should be designed and what they should include and not include are much less valuable than those discussions which revolve around a specific example of the implementation of an idea. The former is sort of more fun, and the later can be more difficult and painful - but I think its ultimately more productive. Obviously, this is a subjective assessment based on one's own personal style and character. I'm sure others will have a different view.

...

Maintain code, docs and tests in parallel

I'm guilty of not doing this, so yes, mentors should *require* their students to have docs and test up to date.

I think that the projects are really in the early stages of development rather than being refined for "release". So I think its pre-mature to insist upon this level of formality. Robert Ramey

JOAQUIN LOPEZ MU?Z wrote:

----- Mensaje original ----- De: Robert Ramey <ramey@rrsd.com>

...

Giovanni Piero Deretta wrote:

...

...

Conduct student-mentor exclusively through public channels This would also be great. While our mentors have been very helpful, more comments on our problems would have been useful. I would mandate> that all *technical* communications should be public.

I have to say I think this is not at all a good idea.

In development of a "speculative" idea, there are lots of failed experiments. Doing this in public would only consume lots of time and distract from job at hand.

I think a better approach would be for software developers (us included) to keep a log of what we've been doing. This would include a record of the failed approaches that had been tried and discarded. This would eventually form the basis of the "rationale" and be very handy when a project is submited for review (formal or otherwise).

Personally, I think the idea of software development as a collaborative activity is overrated. I see it as more personal. Of course criticism (constructive and otherwise) is a public activity. So I think those public dissicussions which speculate on how libraries should be designed and what they should include and not include are much less valuable than those discussions which revolve around a specific example of the implementation of an idea. The former is sort of more fun, and the later can be more difficult and painful - but I think its ultimately more productive.

Hello Robert,

In some sense I agree with you that nothing beats a dedicated mind with focus, time and lack of pressure to produce solid designs upon which others can later build up, discuss etc. But this scenario is different in that it's a student who's doing the work, and the whole thing is supposed to be mentored and validated by the organization. Some guidance is expected and indeed (IMHO) needed, so what the rule about pulic communication tries to fight against is the (possibly natural) tendency of students to try and do all the work on their own without giving the community the possibility to assess the progress and orientation of the project.

Hello Robert and Joaquín, You both have valid points. In the project that I was involved with, Hartmut Kaiser was very visible and was kept in the loop through all the discussions, as did Daveed Vandevoorde (to a certain extent relating to the proposal we were tracking). Hartmut suggested leveraging some prior work that was unknown to me at the time. Hartmut also provided lots of insights based on his experience with the Wave preprocessor. This proved to be very helpful. We still continue discussions with Lally until now, and it's a good thing! The project continued even after SoC. I'm quite satisfied with the results now. Considering the high risk nature of our project, I think now that anything tangible wouldn't have materialized without the participation of Hartmut, given the short time frame. Having said that, I also see Robert's point. There's also some point beyond a certain number of "onlookers" where you get diminishing returns, probably due to the fact that there will be potentially more resistance from diverging opinions and there will be the danger of "design by committee". Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

On 2006-10-21 21:19:22 -0400, Jeff Garland <jeff@crystalclearsoftware.com> said:

...

the Wave preprocessor. This proved to be very helpful. We still continue discussions with Lally until now, and it's a good thing! The project continued even after SoC. I'm quite satisfied with the results now.

You guys might be interested to know that that the committee voted this week to create a TR for modules -- essentially removing it from C++0x. The major problem holding the feature back was the lack of an implementation. By creating the TR, the pursuit of the feature will continue, but an implementation is essential. Couple questions. What's the status of things? Any thought of moving over to gcc and implementing it there?

As a recap for anyone new to the whole project, I was the Boost SoC student working on mfront, a preprocessor that took in Modular C++ and converted it back to C++ for final compilation. It used Wave as a preprocessor, and Spirit as a parsing library, with a slightly modified version of the Hannibal C++ grammar. The grammar is far from complete, but parses a good amount of C++. Modular C++ allowed constructs such as this:

// File_1.cpp: export Lib { // Module definition header. // Must precede all declarations. import std; public: struct S { S() { std::cout << “S()\n”; } }; } // End of module definition (last token).

// File_2.cpp: import Lib; int main() { Lib::S s; }

It doesn't have a full C++ grammar, nor does it maintain a symbol table. Also, it outputs C++, which prevents it from doing any language transformations that require changes in C++ semantics (without re-implementing parts of C+++). Currently, it parses and transforms the base Modular C++ language, along with a module partitions and embedded modules. It can't do the changes in name lookup required, nor does it do some of the 'extras' that weren't part of the core language (e.g. a program module, module startup/shutdown methods, etc.) --- those were left as post v1.0 features. It works by preprocessing its input, transforming the text, and then emitting 3 things: - a source file, to pass into the C++ compiler - a header file - a .map file. The latter two are used for conversion. The .map file declares what modules are defined in which files. The header files are #included by other source files importing the current module. It currently works on Mac OS X, but it's just plain C++ with Boost on it. It compiles on Win32 out of the box. It just needs configuration files written for setting up #include paths, and #defines relevant for the platform. I'm working on Win32 right now, Linux is next. The prioritization order for that work's based the order of which systems are available to me at which time.  As for implementation under GCC instead of as a preprocessor, I think that effort spent in extending the grammar (hannibal) to cover more C++ would have more immediate benefits: - A publically available C++ grammar! - mfront could then become a general testing tool for experimental C++ features. Of course, that'd require we have mfront build a symbol table too, but that'd be just as useful as the grammar itself. The transform engine in mfront is pretty generic, and forms a good basis for experimenting with new C++ features, as long as they can be transformed back into normal C++. IMHO they're a lot easier (full C++, easy access to the input text, only have to output normal C++ text instead of gcc trees) than implementing the equivalent in gcc. Of course, if changing the semantics of C++ is desired, then another solution will be necessary -- mfront would have to translate to C, with the semantics of C++ re-implemented. At that point, modifying an existing compiler's preferable. -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech

Janek Kozicki wrote:

Joaquín M_ López Mu_oz said: (by the date of Thu, 19 Oct 2006 19:29:47 +0200)

couple thoughts on this...

...

http://boost.org/more/boost_soc_06_overview.html

Great report, thanks :)

== Re: 174 applicants, 10 accepted (5.7%).

...

Google initially requested that organizations submitted the maximum number of projects they felt they could cope with, and we got funding for exactly what we aimed for, so the limiting factor lies entirely on Boost's side.

You mentioned that there is a limited number of mentors (10 mentors participated). Since you've written that mentors did not complain about

The limited number of mentors was at least in part driven by our lateness in getting started with the recruiting and evaluation process. We will be more ready next year. In addition, Google has said they are going to move the organization approval process back to Feb/Mar timeframe, so there will be a bit more time to get organized next year.

lack of time spent on mentoring, then perhaps next year a single mentor could be allowed to mentor two projects, if he feels that he can fullfill the task?

I'd say this is a very bad idea based on the results of other SOC projects. Many 2nd year organizations reported a very high dropout rate for mentors and thus had to reduce the number of projects in year 2. Much of this seemed to be related to mentors handling multiple students being way to busy. Among the folks I talked with at the SoC mentor summit, it seemed clear that 1 to 1 was really the best way to go. In addition to that, I believe for the evaluation phase we really want to have more mentors so we can give submissions and applicants all the attention they deserve. It was a *huge* struggle for the mentors to handle those 174 submissions.... Jeff

Janek Kozicki wrote:

J

...

...

lack of time spent on mentoring, then perhaps next year a single mentor could be allowed to mentor two projects, if he feels that he can fullfill the task? I'd say this is a very bad idea based on the results of other SOC projects.

ok. I'm sorry :) you are right. quality first, quantity second :)

Absolutely no reason to be sorry...there's no way you would know that information without me conveying it :-) And I should say, that we are all certainly open to suggestions/discussion about how to improve our SoC participation for next year. Jeff