Hi Grigori, About the wiki page http://gcc.gnu.org/wiki/SummerOfCode
Perhaps the table format for specific project ideas is clearer than the bullet list format. However, we should not have two formats. If the table is preferred, I suggest that other people that have added ideas in a bullet list format, update the wiki page and add their ideas to the table. However, you know that project proposals are submitted by students, don't you? The way you wrote it in the wiki suggests (to me) that mentors submit projects and then students are recruited. I have modified it to avoid this confusion. Also, you do not give contact information in the table, so what is the point of listing who is interested? Furthermore, as far as I know, there is only one student per project, and students may not wish to see their name listed in a wiki page if their project was ultimately not accepted. So I do not see the point of the column student. Students should contact the project contact or the gcc list and ask for mentors. Cheers, Manuel. 2009/2/26 Sebastian Pop <seb...@gmail.com>: > Hi Grigori, > > On Thu, Feb 26, 2009 at 04:57, Grigori Fursin <grigori.fur...@inria.fr> wrote: >> Hello All, >> >> I just saw an announcement that a new Google Summer of Code'2009 >> (http://code.google.com/soc) will be accepting project proposals >> in a week or so. My colleagues and I would like to submit a few proposals >> so wanted to ask if someone is interested in that to synchronize submissions. >> >> Basically, within last 2 years we had some interesting results on collective >> program optimizations and predictive modeling from the MILEPOST project and >> we >> would like to extend the following projects to move our technology to the >> community >> (also based on the feedback from our users and GROW workshop participants): >> >> 1) extend GCC plugin framework/ICI/MILEPOST framework to enable fine-grain >> transformation parameter tuning. Currently we can perform search for good >> combinations of passes, their orders and parameter tuning on function level >> and we would like to be able to do it for each individual transformation >> to tune optimization heuristic for GRAPHITE loop transformations, loop >> vectorization, >> inlining, unrolling, etc. >> > > I would be pleased to co-advise the student/s working on projects > related to Graphite and loop transforms. > > Sebastian >
