Re: Google Summer of Code - Ideas List, please discuss

[Janek Warchoł]

W dniu 12 lutego 2012 15:13 użytkownik Graham Percival
<address@hidden> napisał:
> On Sun, Feb 12, 2012 at 12:03:48PM +0100, Janek Warchoł wrote:
>> 2) Adding comprehensive MusicXML import and export features, together
>> with test suites for it.  Requirements: ? (no idea in which language
>> this would be written), MusicXML, basic LilyPond and music notation
>> knowledge; familiarity with other scorewriters would be a nice bonus
>> (for cross-testing).  The goal would be considered achieved when a
>> (previously chosen) not-so-complicated score could be imported from
>> MusicXML and exported back with no (unintentional) loss of data.
>
> umm, you know that we already have musicxml2ly import, right?

Yes.  I had some issues with it - dynamics got attached to wrong
notes.  So i basically meant "improve import and add export".

> I agree with having this on the ideas list, but it should
> definitely mention musicxml2ly.py and basic familiarity with
> python.

Sure.

>> 5) Build System Improvement: if we want to ever move away from make,
>> this would be a good opportunity.  Issues like thousands of errors and
>> warnings during compilation should be removed, all dependancies fixed
>> (so that one doesn't need to remove fonts folder to have fonts
>> rebuilt).  Requirements: Python, Make and (optionally) another build
>> system.
>
> I think this item needs rewriting.  If Phil and Julien want to
> highlight exactly what is left, great; otherwise I'd be tempted to
> leave it out.
>
> Then again, it's just possible that Phil or Julien might be
> interested in being student in GSoC, in which case we should
> definitely include this as a project.

Students can add their own proposals, ideas list is more like a
guideline.  So there will be no problem leaving this out and then
having Phil or Julien formulate their own proposal when they apply.

> I'd add another item to the list:
> n+1) clean up compiler warnings, static code analysis, and
> valgrind warnings.  Automatic code analysis tools (warnings in g++
> and clang) and analysis tools like valgrind memory leak detection
> and callgrind code profilers provide valuable information about
> possible flaws in C++ code.  It would be great if somebody could
> clean up those warnings, as this would allow us to automatically
> reject any patch which introduced extra warnings.  Once compiler
> warnings are fixed, analysis of memory leaks and profiling would
> be great.

that's nice.

thanks,
Janek