--- /dev/null
+@c -*- coding: utf-8; mode: texinfo; -*-
+@c This file is part of community.itexi
+@c It's been moved here to reduce maintenance burden on translators. It's up
+@c to translators the choice of translating this section of community.itexi or
+@c not (as GSoC students are required to speak english, a translated page is
+@c not needed).
+
+@c Current proposals for Google Summer of Code
+@macro gsocCurrent
+
+@divClass{column-center-top}
+@subheading What is Google Summer of Code?
+
+@uref{https://summerofcode.withgoogle.com/, GSoC} is a global program
+that offers students stipends to write code for free software and open
+source projects during the summer. For three months students work to
+complete a given task as part of the project's community and under the
+guidance of experienced mentors. The program is an excellent
+opportunity for students to gain experience with real-world software
+development and make a contribution that benefits everyone. It brings
+new contributors to LilyPond and enables students who are already
+involved to become more involved. LilyPond participates in GSoC as part
+of the @uref{http://www.gnu.org/, GNU project}.
+
+We have had GSoC participants in 2012, 2015 and 2016 and encourage
+students to apply for the 2017 program.
+
+If you are interested to apply for the program with LilyPond as a
+project, please read the information below and don't hesitate to write
+us on our developer mailing list (see @ref{Contact}). The student
+application window is March 20 to April 3, 2017, but we strongly
+encourage you to get in touch with our community ahead of that.
+
+@divEnd
+
+@divClass{column-center-middle-color2 bigger-subsubheadings}
+@subheading Project Ideas List
+
+Below is a list of GSoC project ideas (last update: January 2017), but
+if you have other ideas for a project you may complete within the three
+months of the program you're welcome to make a suggestion on our
+developer mailing list (see @ref{Contact}). There are a number of areas
+where LilyPond could be improved, and our development team is always
+willing to help those who would like to tackle a project similar to
+those listed below. As mentor availability varies from project to
+project and from year to year it is wise to get in touch with us as
+early as possible.
+
+A full list of all the current open issues can be found
+@uref{http://sourceforge.net/p/testlilyissues/issues/, here}.
+
+
+@subsubheading Improve internal chord structure
+
+The internal representation of LilyPond chords is not powerful enough
+to capture the nomenclature of jazz chords. Currently the chord has
+a root, a bass and an inversion. It would be nice to be able to handle
+stacked or polychords, minor/major, etc. In order to do this, an
+internal representation with the ability to capture the essence of
+complex chords must be developed. As a bonus, once the internal
+representation is developed, the output formatting of chord names can
+be improved.
+
+@emph{Difficulty:} Easy/medium
+
+@emph{Requirements:} Scheme (Guile), but the level necessary can be
+easily learned
+
+@emph{Recommended:} Chord theory and naming
+
+@emph{Mentor:} Carl Sorensen
+
+
+@subsubheading Adopt the SMuFL music font encoding standard
+
+For several years now a new standard for music fonts has been around:
+@uref{http://www.smufl.org/, SMuFL}, which is also discussed as becoming part of
+a future W3C standard for music encoding. As a FLOSS tool LilyPond should
+adhere to such an open standard instead of using an isolated solution like it
+does today. Adopting SMuFL will help integrating LilyPond with the world of
+music notation software and eventually give LilyPond users access to a wider
+selection of notation fonts.
+
+Making LilyPond compliant to SMuFL includes remapping of the glyphs that are
+built from METAFONT sources, adjusting the glyphs' metrics to SMuFL's
+specifications, and finally updating the way LilyPond looks up and positions the
+glyphs. As an optional part of this project LilyPond's font loading mechanism
+could be modified to use notation fonts installed as system fonts instead of
+inside the LilyPond installation.
+
+@emph{Difficulty}: Easy/medium
+
+@emph{Requirements}: C++ and willingness to get familiar with LilyPond
+internals.
+
+@emph{Recommended}: Interest and experience in working with font files.
+A little bit of METAFONT.
+
+@emph{Mentors}: Werner Lemberg, Abraham Lee
+
+
+@subsubheading Adding variants of font glyphs
+
+@divClass{keep-bullets}
+@itemize
+
+@item
+Adding @q{on} and @q{between} staff-line variants.
+
+@item
+Shorter and narrower variants of some glyphs for example, accidentals.
+Another, more specific example could be an ancient notation breve
+notehead coming in two variants one with a small or big @q{hole} within
+it.
+
+@end itemize
+@divEnd
+
+@emph{Difficulty:} easy
+
+@emph{Requirements:} MetaFont, C++, good eye for details
+
+@emph{Recommended knowledge:} basic LilyPond knowledge
+
+@emph{Mentor:} Werner Lemberg
+
+
+@subsubheading Contemporary Notation
+
+LilyPond is very good at creating non-standard notation. Having to
+@emph{code} every graphical element instead of simply @emph{drawing}
+it may seem cumbersome but is in fact a strong asset. New notational
+functionality can be provided with consistent appearance, automatic
+layout and a natural syntactic interface.
+
+Within the @uref{https://github.com/openlilylib/oll-core, openLilyLib}
+library system the student will create a fundamental infrastructure
+and building blocks to make creating contemporary notation easier.
+Additionally (at least) @emph{one} concrete package is developed to
+cover specific contemporary notation, such as for example the style
+of a given composer, extended playing techniques for a specific
+instrument or a certain category of effects.
+
+@emph{Difficulty:} medium
+
+@emph{Requirements:} Scheme (interaction with LilyPond internals),
+contemporary notation techniques
+
+@emph{Recommended:} sense of building hierarchical frameworks
+
+@emph{Mentors:} @emph{NN,} Urs Liska
+
+
+@subsubheading Rewrite LibreOffice LilyPond Extension with Python
+
+The @uref{http://ooolilypond.sourceforge.net/, OOoLilyPond} extension
+made it possible to conveniently include LilyPond score snippets in
+OpenOffice.org/LibreOffice Writer, Draw and Impress documents while
+keeping source and image together. After many years without development
+an initial effort has started to make the extension compatible again
+with current versions of LibreOffice and LilyPond.
+
+However, as the LibreOffice ecosystem has changed substantially it is
+now possible to rewrite the extension with Python and PyQt. This will
+not only be more powerful in general but will allow the integration of
+functionality from @uref{http://frescobaldi.org, Frescobaldi}, such as
+for example syntax highlighting, entry helpers, score wizards or musical
+transformations.
+
+@emph{Difficulty:} easy/medium
+
+@emph{Requirements:} Python, PyQt, LilyPond basics, LibreOffice
+extension basics
+
+@emph{Recommended knowledge:} Familiarity with Frescobaldi code based
+or willingness to learn during bonding period
+
+@emph{Mentor(s):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)
+
+
+@subsubheading Automated testing and documentation for openLilyLib
+
+@uref{https://github.com/openlilylib, openLilyLib} is an extension
+framework for LilyPond code providing a “snippets” repository and a
+suite of integrated packages such as for example page layout tools or
+scholarly annotations. It is very powerful and promising, but to really
+get off the ground two features are missing: automated testing and
+documentation generation.
+
+Automated testing is necessary to ensure modifications to functionality
+don't break other functions within the library. There is already some
+Automated Testing of the “snippets” repository with Github's Travis
+server, but this has to be reconsidered and extended to cover the
+standalone packages too.
+
+In order to be usable for a wider range of LilyPond users on a “consumer
+level” openLilyLib needs proper documentation. This documentation has
+to be generated from the sources, so a system is needed that requires
+package authors to document the input files and provide additional usage
+examples, from which documentation is generated. Ideally but not
+necessarily this is implemented as a Git hook, i.e. automatically upon
+each update to the repository. We don't prescribe the tools and
+approaches to be used, but the most widely used language in the LilyPond
+domain is Python, so there would be some bias towards that.
+Alternatively a Scheme solution could be fine so generating the
+documentation would actually be triggered by “compiling” a certain
+LilyPond input file. In general it is advisable to make use of proven
+concepts and tools from other languages.
+
+The eventual output of the documentation should be a static HTML site
+that can be viewed locally and/or uploaded to a website. But it would
+be beneficial if the tool would first generate an intermediate
+representation (e.g. a JSON file with additional media files) from which
+a Single Page Application could retrieve content for display on
+openLilyLib's @uref{https://openlilylib.org, website}. Development of
+such a SPA @emph{can} be part of the GSoC project, but is optional.
+
+@emph{Difficulty:} medium
+
+@emph{Requirements:} Python or Scheme, static website generator(s) or
+(Node.js based) dynamic web application technology. Continuous
+Integration (can be learned during the bonding period)
+
+@emph{Mentors:} Urs Liska, Matteo Ceccarello
+
+
+@subsubheading MusicXML
+
+Improving MusicXML import and export functions:
+
+File interchange between LilyPond and other applications using MusicXML
+is still a difficult matter. To import MusicXML it has to be converted
+manually by the @code{musicxml2ly} script. Export @emph{to} MusicXML is
+only available as a rudimentary feature inside Frescobaldi. In order to
+provide natural interchange between LilyPond and MusicXML based
+applications there's the need of actual import functionality and a
+dedicated export backend.
+
+Importing XML shall provide file, line and column to add origin
+attributes to generated objects. That way point and click can be
+made available in Frescobaldi or other supported IDEs.
+
+Exporting XML shall be realized with an exporter class like the MIDI
+export. This may be based on the work already done in
+@uref{https://github.com/DavidGarfinkle/Lilypond_MusicXMLexport, GSoC 2015}
+by David Garfinkle. It should be checked if it is possible to use
+another XML library than the one provided by guile-2 in order to have
+this feature available in current LilyPond (which is based on guile-1.8).
+
+@emph{Difficulty:} medium
+
+@emph{Requirements:} MusicXML, Python, Scheme, basic LilyPond knowledge
+
+@emph{Recommended:} Familiarity with other scorewriters (for cross-testing)
+
+@emph{Mentor:} Jan-Peter Voigt
+
+@divEnd
+
+
+@divClass{column-center-middle-color2}
+@subheading Information for Applicants/Participants
+
+In order to have a satisfying experience with GSoC applicants are
+strongly advised to thoroughly read the following recommendations. Some
+of these are relevant for the application process, others for the time
+within the project.
+
+@itemize
+
+@item
+Read all applicable information on the program's website, particularly
+the
+@uref{https://developers.google.com/open-source/gsoc/resources/manual,
+students' manual}. Make sure you fulfil all of Google's prerequisites
+and are willing to join the program as a full-time commitment over the
+coding period of three months.
+
+@item
+Please get in touch with us as soon as possible if you are interested in
+applying with a project. Mentor availability may change without notice,
+project proposals may need fine-tuning, and many other reasons might
+require us to reject or ignore an application that hasn't been discussed
+before.
+
+@item
+We do not know in advance how many “slots” we will have available for
+projects, so please be aware that you may find yourself in competition
+with other applicants or not. Interested or even enthusiastic response
+from our mentors is no guarantee of eventually being accepted, and
+@emph{not} being accepted does not necessarily indicate a negative
+evaluation of your application. If we have to decide between different
+applicants there may be various aspects to consider.
+
+@item
+Integration in the LilyPond community is a fundamental part of GSoC, and
+we expect our students to make substantial efforts to become community
+members. Within the @emph{bonding period} we expect you to write a blog
+post about your project (either on @uref{http://lilypondblog.org, Scores
+of Beauty} or on any other blog) and to be active on our mailing lists,
+introducing yourself but also communicating about unrelated tasks. This
+goes beyond the mere setting up of a working environment and
+familiarizing yourself with the relevant code, but we think it is
+crucial for the GSoC project to be mutually satisfying.
+
+@item
+If you are accepted to the program you will have one mentor explicitly
+assigned to your project. With this mentor you will have to agree upon
+a communication strategy, be it emails, chatrooms, issue trackers or
+voice/video chats. Regular communication is absolutely crucial for the
+success of a GSoC project so you are stricly required to keep talking to
+your mentor. But keep in mind that your mentor has explicitly taken
+over the responsibility for your project, and while unlike you he isn't
+paid for this activity you are still entitled to get regular attention
+from him.
+
+@item
+In order to get support from your mentor you have to give him a chance
+to follow your progress and efforts. Therefore it is important to
+regularly commit your changes to the versioning repository you are
+working on. Don't hesitate making unfinished code available because you
+are afraid of criticism, and don't suppress questions because you think
+they might be considered stupid. But ideally your code should at any
+time be accompanied by compatible testing code. Your mentor may not be
+able to properly assess your code by only @emph{reading} it without the
+opportunity to apply it in a real example.
+
+@end itemize
+
+There is a list of inactive projects in the @ref{Attic}. We list
+projects there that are still considered valuable but for which there
+are currently no mentors available.
+
+@divEnd
+@end macro
+
+
+@c Inactive proposals for Google Summer of Code
+@macro gsocInactive
+@subheading Inactive Google Summer of Code project suggestions
+
+The following list describes GSoC projects that had been proposed
+in recent years and which are still considered valuable but for
+which we currently don't have mentors available.
+
+
+@subsubheading Improve slurs and ties
+
+The engraving quality of slurs and ties is often unsatisfactory. Ties
+@q{broken} by clef or staff changes are not handled well. The project
+could include collecting and sorting examples of bad output, deciding on
+the intended output and writing code to improve them.
+
+@emph{Difficulty:} hard
+
+@emph{Requirements:} C++, experience with writing heuristics
+
+@emph{Recommended knowledge:} LilyPond knowledge, aesthetic sense
+
+
+@subsubheading Grace notes
+
+Fix problems with synchronization of grace notes. Grace notes can
+interfere with LilyPond's timing and cause odd effects, especially when
+multiple staffs are used where some have grace notes and others don't.
+This is one of the longest-standing and one of the more embarrassing
+@uref{https://sourceforge.net/p/testlilyissues/issues/34/,bugs} in
+LilyPond.
+
+@emph{Difficulty:} medium
+
+@emph{Requirements:} C++, MIDI
+
+@emph{Recommended:} familiarity with LilyPond internals
+
+
+@subsubheading Improve default beam positioning
+
+For regular, cross-staff, broken and kneed beams. Beaming should depend
+on context and neighbor notes (see section 2.2 of
+@uref{http://imslp.org/wiki/Repository_of_Music-Notation_Mistakes_%28Coulon%2C_Jean-Pierre%29,
+this book}). If possible also reduce beaming-computation time.
+
+@emph{Difficulty:} medium
+
+@emph{Requirements:} C++, experience with writing heuristics
+
+@emph{Recommended knowledge:} aesthetic sense
+
+
+@subsubheading Help improve compilation behavior
+
+Automatic code analysis tools, like valgrind memory leak detection or
+callgrind code profilers, provide valuable information about possible
+flaws in our C++ code. Cleaning up warnings would allow us to automate
+the rejection of any patch which introduced extra warnings.
+
+@emph{Difficulty:} medium
+
+@emph{Requirements:} C++
+
+@end macro
@include included/acknowledge.itexi
@include included/authors.itexi
+@include included/gsoc.itexi
@include included/helpus.itexi
@node Community
@node Google Summer of Code
@unnumberedsec Google Summer of Code
-@divClass{column-center-top}
-@subheading What is Google Summer of Code?
-
-@uref{https://summerofcode.withgoogle.com/, GSoC} is a global program
-that offers students stipends to write code for free software and open
-source projects during the summer. For three months students work to
-complete a given task as part of the project's community and under the
-guidance of experienced mentors. The program is an excellent
-opportunity for students to gain experience with real-world software
-development and make a contribution that benefits everyone. It brings
-new contributors to LilyPond and enables students who are already
-involved to become more involved. LilyPond participates in GSoC as part
-of the @uref{http://www.gnu.org/, GNU project}.
-
-We have had GSoC participants in 2012, 2015 and 2016 and encourage
-students to apply for the 2017 program.
-
-If you are interested to apply for the program with LilyPond as a
-project, please read the information below and don't hesitate to write
-us on our developer mailing list (see @ref{Contact}). The student
-application window is March 20 to April 3, 2017, but we strongly
-encourage you to get in touch with our community ahead of that.
-
-@divEnd
-
-@divClass{column-center-middle-color2 bigger-subsubheadings}
-@subheading Project Ideas List
-
-Below is a list of GSoC project ideas (last update: January 2017), but
-if you have other ideas for a project you may complete within the three
-months of the program you're welcome to make a suggestion on our
-developer mailing list (see @ref{Contact}). There are a number of areas
-where LilyPond could be improved, and our development team is always
-willing to help those who would like to tackle a project similar to
-those listed below. As mentor availability varies from project to
-project and from year to year it is wise to get in touch with us as
-early as possible.
-
-A full list of all the current open issues can be found
-@uref{http://sourceforge.net/p/testlilyissues/issues/, here}.
-
-
-@subsubheading Improve internal chord structure
-
-The internal representation of LilyPond chords is not powerful enough
-to capture the nomenclature of jazz chords. Currently the chord has
-a root, a bass and an inversion. It would be nice to be able to handle
-stacked or polychords, minor/major, etc. In order to do this, an
-internal representation with the ability to capture the essence of
-complex chords must be developed. As a bonus, once the internal
-representation is developed, the output formatting of chord names can
-be improved.
-
-@emph{Difficulty:} Easy/medium
-
-@emph{Requirements:} Scheme (Guile), but the level necessary can be
-easily learned
-
-@emph{Recommended:} Chord theory and naming
-
-@emph{Mentor:} Carl Sorensen
-
-
-@subsubheading Adopt the SMuFL music font encoding standard
-
-For several years now a new standard for music fonts has been around:
-@uref{http://www.smufl.org/, SMuFL}, which is also discussed as becoming part of
-a future W3C standard for music encoding. As a FLOSS tool LilyPond should
-adhere to such an open standard instead of using an isolated solution like it
-does today. Adopting SMuFL will help integrating LilyPond with the world of
-music notation software and eventually give LilyPond users access to a wider
-selection of notation fonts.
-
-Making LilyPond compliant to SMuFL includes remapping of the glyphs that are
-built from METAFONT sources, adjusting the glyphs' metrics to SMuFL's
-specifications, and finally updating the way LilyPond looks up and positions the
-glyphs. As an optional part of this project LilyPond's font loading mechanism
-could be modified to use notation fonts installed as system fonts instead of
-inside the LilyPond installation.
-
-@emph{Difficulty}: Easy/medium
-
-@emph{Requirements}: C++ and willingness to get familiar with LilyPond
-internals.
-
-@emph{Recommended}: Interest and experience in working with font files.
-A little bit of METAFONT.
-
-@emph{Mentors}: Werner Lemberg, Abraham Lee
-
-
-@subsubheading Adding variants of font glyphs
-
-@divClass{keep-bullets}
-@itemize
-
-@item
-Adding @q{on} and @q{between} staff-line variants.
-
-@item
-Shorter and narrower variants of some glyphs for example, accidentals.
-Another, more specific example could be an ancient notation breve
-notehead coming in two variants one with a small or big @q{hole} within
-it.
-
-@end itemize
-@divEnd
-
-@emph{Difficulty:} easy
-
-@emph{Requirements:} MetaFont, C++, good eye for details
-
-@emph{Recommended knowledge:} basic LilyPond knowledge
-
-@emph{Mentor:} Werner Lemberg
-
-
-@subsubheading Contemporary Notation
-
-LilyPond is very good at creating non-standard notation. Having to
-@emph{code} every graphical element instead of simply @emph{drawing}
-it may seem cumbersome but is in fact a strong asset. New notational
-functionality can be provided with consistent appearance, automatic
-layout and a natural syntactic interface.
-
-Within the @uref{https://github.com/openlilylib/oll-core, openLilyLib}
-library system the student will create a fundamental infrastructure
-and building blocks to make creating contemporary notation easier.
-Additionally (at least) @emph{one} concrete package is developed to
-cover specific contemporary notation, such as for example the style
-of a given composer, extended playing techniques for a specific
-instrument or a certain category of effects.
-
-@emph{Difficulty:} medium
-
-@emph{Requirements:} Scheme (interaction with LilyPond internals),
-contemporary notation techniques
-
-@emph{Recommended:} sense of building hierarchical frameworks
-
-@emph{Mentors:} @emph{NN,} Urs Liska
-
-
-@subsubheading Rewrite LibreOffice LilyPond Extension with Python
-
-The @uref{http://ooolilypond.sourceforge.net/, OOoLilyPond} extension
-made it possible to conveniently include LilyPond score snippets in
-OpenOffice.org/LibreOffice Writer, Draw and Impress documents while
-keeping source and image together. After many years without development
-an initial effort has started to make the extension compatible again
-with current versions of LibreOffice and LilyPond.
-
-However, as the LibreOffice ecosystem has changed substantially it is
-now possible to rewrite the extension with Python and PyQt. This will
-not only be more powerful in general but will allow the integration of
-functionality from @uref{http://frescobaldi.org, Frescobaldi}, such as
-for example syntax highlighting, entry helpers, score wizards or musical
-transformations.
-
-@emph{Difficulty:} easy/medium
-
-@emph{Requirements:} Python, PyQt, LilyPond basics, LibreOffice
-extension basics
-
-@emph{Recommended knowledge:} Familiarity with Frescobaldi code based
-or willingness to learn during bonding period
-
-@emph{Mentor(s):} Joram Berger, Urs Liska, (Thorsten Behrens/LibreOffice)
-
-
-@subsubheading Automated testing and documentation for openLilyLib
-
-@uref{https://github.com/openlilylib, openLilyLib} is an extension
-framework for LilyPond code providing a “snippets” repository and a
-suite of integrated packages such as for example page layout tools or
-scholarly annotations. It is very powerful and promising, but to really
-get off the ground two features are missing: automated testing and
-documentation generation.
-
-Automated testing is necessary to ensure modifications to functionality
-don't break other functions within the library. There is already some
-Automated Testing of the “snippets” repository with Github's Travis
-server, but this has to be reconsidered and extended to cover the
-standalone packages too.
-
-In order to be usable for a wider range of LilyPond users on a “consumer
-level” openLilyLib needs proper documentation. This documentation has
-to be generated from the sources, so a system is needed that requires
-package authors to document the input files and provide additional usage
-examples, from which documentation is generated. Ideally but not
-necessarily this is implemented as a Git hook, i.e. automatically upon
-each update to the repository. We don't prescribe the tools and
-approaches to be used, but the most widely used language in the LilyPond
-domain is Python, so there would be some bias towards that.
-Alternatively a Scheme solution could be fine so generating the
-documentation would actually be triggered by “compiling” a certain
-LilyPond input file. In general it is advisable to make use of proven
-concepts and tools from other languages.
-
-The eventual output of the documentation should be a static HTML site
-that can be viewed locally and/or uploaded to a website. But it would
-be beneficial if the tool would first generate an intermediate
-representation (e.g. a JSON file with additional media files) from which
-a Single Page Application could retrieve content for display on
-openLilyLib's @uref{https://openlilylib.org, website}. Development of
-such a SPA @emph{can} be part of the GSoC project, but is optional.
-
-@emph{Difficulty:} medium
-
-@emph{Requirements:} Python or Scheme, static website generator(s) or
-(Node.js based) dynamic web application technology. Continuous
-Integration (can be learned during the bonding period)
+@gsocCurrent
-@emph{Mentors:} Urs Liska, Matteo Ceccarello
-
-
-@subsubheading MusicXML
-
-Improving MusicXML import and export functions:
-
-File interchange between LilyPond and other applications using MusicXML
-is still a difficult matter. To import MusicXML it has to be converted
-manually by the @code{musicxml2ly} script. Export @emph{to} MusicXML is
-only available as a rudimentary feature inside Frescobaldi. In order to
-provide natural interchange between LilyPond and MusicXML based
-applications there's the need of actual import functionality and a
-dedicated export backend.
-
-Importing XML shall provide file, line and column to add origin
-attributes to generated objects. That way point and click can be
-made available in Frescobaldi or other supported IDEs.
-
-Exporting XML shall be realized with an exporter class like the MIDI
-export. This may be based on the work already done in
-@uref{https://github.com/DavidGarfinkle/Lilypond_MusicXMLexport, GSoC 2015}
-by David Garfinkle. It should be checked if it is possible to use
-another XML library than the one provided by guile-2 in order to have
-this feature available in current LilyPond (which is based on guile-1.8).
-
-@emph{Difficulty:} medium
-
-@emph{Requirements:} MusicXML, Python, Scheme, basic LilyPond knowledge
-
-@emph{Recommended:} Familiarity with other scorewriters (for cross-testing)
-
-@emph{Mentor:} Jan-Peter Voigt
-
-@divEnd
-
-
-@divClass{column-center-middle-color2}
-@subheading Information for Applicants/Participants
-
-In order to have a satisfying experience with GSoC applicants are
-strongly advised to thoroughly read the following recommendations. Some
-of these are relevant for the application process, others for the time
-within the project.
-
-@itemize
-
-@item
-Read all applicable information on the program's website, particularly
-the
-@uref{https://developers.google.com/open-source/gsoc/resources/manual,
-students' manual}. Make sure you fulfil all of Google's prerequisites
-and are willing to join the program as a full-time commitment over the
-coding period of three months.
-
-@item
-Please get in touch with us as soon as possible if you are interested in
-applying with a project. Mentor availability may change without notice,
-project proposals may need fine-tuning, and many other reasons might
-require us to reject or ignore an application that hasn't been discussed
-before.
-
-@item
-We do not know in advance how many “slots” we will have available for
-projects, so please be aware that you may find yourself in competition
-with other applicants or not. Interested or even enthusiastic response
-from our mentors is no guarantee of eventually being accepted, and
-@emph{not} being accepted does not necessarily indicate a negative
-evaluation of your application. If we have to decide between different
-applicants there may be various aspects to consider.
-
-@item
-Integration in the LilyPond community is a fundamental part of GSoC, and
-we expect our students to make substantial efforts to become community
-members. Within the @emph{bonding period} we expect you to write a blog
-post about your project (either on @uref{http://lilypondblog.org, Scores
-of Beauty} or on any other blog) and to be active on our mailing lists,
-introducing yourself but also communicating about unrelated tasks. This
-goes beyond the mere setting up of a working environment and
-familiarizing yourself with the relevant code, but we think it is
-crucial for the GSoC project to be mutually satisfying.
-
-@item
-If you are accepted to the program you will have one mentor explicitly
-assigned to your project. With this mentor you will have to agree upon
-a communication strategy, be it emails, chatrooms, issue trackers or
-voice/video chats. Regular communication is absolutely crucial for the
-success of a GSoC project so you are stricly required to keep talking to
-your mentor. But keep in mind that your mentor has explicitly taken
-over the responsibility for your project, and while unlike you he isn't
-paid for this activity you are still entitled to get regular attention
-from him.
-
-@item
-In order to get support from your mentor you have to give him a chance
-to follow your progress and efforts. Therefore it is important to
-regularly commit your changes to the versioning repository you are
-working on. Don't hesitate making unfinished code available because you
-are afraid of criticism, and don't suppress questions because you think
-they might be considered stupid. But ideally your code should at any
-time be accompanied by compatible testing code. Your mentor may not be
-able to properly assess your code by only @emph{reading} it without the
-opportunity to apply it in a real example.
-
-@end itemize
-
-There is a list of inactive projects in the @ref{Attic}. We list
-projects there that are still considered valuable but for which there
-are currently no mentors available.
-
-@divEnd
@node Authors
@unnumberedsec Authors
@divEnd
@divClass{column-center-middle-color2 bigger-subsubheadings}
-@subheading Inactive Google Summer of Code project suggestions
-
-The following list describes GSoC projects that had been proposed
-in recent years and which are still considered valuable but for
-which we currently don't have mentors available.
-
-
-@subsubheading Improve slurs and ties
-
-The engraving quality of slurs and ties is often unsatisfactory. Ties
-@q{broken} by clef or staff changes are not handled well. The project
-could include collecting and sorting examples of bad output, deciding on
-the intended output and writing code to improve them.
-
-@emph{Difficulty:} hard
-
-@emph{Requirements:} C++, experience with writing heuristics
-
-@emph{Recommended knowledge:} LilyPond knowledge, aesthetic sense
-
-
-@subsubheading Grace notes
-
-Fix problems with synchronization of grace notes. Grace notes can
-interfere with LilyPond's timing and cause odd effects, especially when
-multiple staffs are used where some have grace notes and others don't.
-This is one of the longest-standing and one of the more embarrassing
-@uref{https://sourceforge.net/p/testlilyissues/issues/34/,bugs} in
-LilyPond.
-
-@emph{Difficulty:} medium
-
-@emph{Requirements:} C++, MIDI
-
-@emph{Recommended:} familiarity with LilyPond internals
-
-
-@subsubheading Improve default beam positioning
-
-For regular, cross-staff, broken and kneed beams. Beaming should depend
-on context and neighbor notes (see section 2.2 of
-@uref{http://imslp.org/wiki/Repository_of_Music-Notation_Mistakes_%28Coulon%2C_Jean-Pierre%29,
-this book}). If possible also reduce beaming-computation time.
-
-@emph{Difficulty:} medium
-
-@emph{Requirements:} C++, experience with writing heuristics
-
-@emph{Recommended knowledge:} aesthetic sense
-
-
-@subsubheading Help improve compilation behavior
-
-Automatic code analysis tools, like valgrind memory leak detection or
-callgrind code profilers, provide valuable information about possible
-flaws in our C++ code. Cleaning up warnings would allow us to automate
-the rejection of any patch which introduced extra warnings.
-
-@emph{Difficulty:} medium
-
-@emph{Requirements:} C++
-
+@gsocInactive
@divEnd
@divClass{column-center-middle-color2}
SCM mark_smob () const;
static const char * const type_p_name_;
virtual ~Lily_lexer ();
+ int scan_word (SCM & output, SCM sym);
private:
int lookup_keyword (const string&);
int scan_bare_word (const string&);
s = lyric_fudge (s);
yylval = ly_string2scm (s);
- return STRING;
+ return WORD;
}
/* This should really just cover {} */
[{}] {
string s (YYText_utf8 ());
yylval = ly_string2scm (s);
- return STRING;
+ return WORD;
}
[{}] {
yylval = SCM_UNSPECIFIED;
yylval = ly_string2scm (str);
- return STRING;
+ return STRING; // WORD would cause additional processing
}
int
}
int
-Lily_lexer::scan_bare_word (const string &str)
+Lily_lexer::scan_word (SCM & output, SCM sym)
{
- SCM sym = ly_symbol2scm (str.c_str ());
if ((YYSTATE == notes) || (YYSTATE == chords)) {
SCM handle = SCM_BOOL_F;
if (scm_is_pair (pitchname_tab_stack_))
handle = scm_hashq_get_handle (scm_cdar (pitchname_tab_stack_), sym);
if (scm_is_pair (handle)) {
- yylval = scm_cdr (handle);
+ output = scm_cdr (handle);
if (unsmob<Pitch> (yylval))
return (YYSTATE == notes) ? NOTENAME_PITCH : TONICNAME_PITCH;
else if (scm_is_symbol (yylval))
else if ((YYSTATE == chords)
&& scm_is_true (handle = scm_hashq_get_handle (chordmodifier_tab_, sym)))
{
- yylval = scm_cdr (handle);
+ output = scm_cdr (handle);
return CHORD_MODIFIER;
}
}
+ output = SCM_UNDEFINED;
+ return -1;
+}
+
+int
+Lily_lexer::scan_bare_word (const string &str)
+{
+ int state = scan_word (yylval, ly_symbol2scm (str.c_str ()));
+ if (state >= 0)
+ {
+ return state;
+ }
yylval = ly_string2scm (str);
- return STRING;
+ return WORD;
}
int
SCM make_simple_markup (SCM a);
SCM make_duration (SCM t, int dots = 0, SCM factor = SCM_UNDEFINED);
bool is_regular_identifier (SCM id, bool multiple=false);
+SCM make_reverse_key_list (SCM keys);
+SCM try_word_variants (SCM pred, SCM str);
SCM try_string_variants (SCM pred, SCM str);
int yylex (YYSTYPE *s, YYLTYPE *loc, Lily_parser *parser);
%token STRING
%token SYMBOL_LIST
%token TONICNAME_PITCH
+%token WORD
%left '-' '+'
DECLARATIONS
*/
assignment_id:
- STRING { $$ = $1; }
+ STRING
+ | WORD
;
assignment:
}
;
-// symbol_list_part delivers elements in reverse copy.
+// symbol_list_part delivers elements in reverse copy, no lookahead
symbol_list_part:
- symbol_list_element
+ symbol_list_part_bare
+ | embedded_scm_bare
{
- $$ = try_string_variants (Lily::key_list_p, $1);
+ $$ = make_reverse_key_list ($1);
if (SCM_UNBNDP ($$)) {
parser->parser_error (@1, _("not a key"));
$$ = SCM_EOL;
- } else
- $$ = scm_reverse ($$);
+ }
}
;
symbol_list_element:
STRING
- | embedded_scm_bare
+ {
+ $$ = scm_string_to_symbol ($1);
+ }
| UNSIGNED
;
+
symbol_list_part_bare:
- STRING
+ WORD
{
- $$ = try_string_variants (Lily::key_list_p, $1);
+ $$ = try_word_variants (Lily::key_list_p, $1);
if (SCM_UNBNDP ($$)) {
parser->parser_error (@1, _("not a key"));
$$ = SCM_EOL;
} else
$$ = scm_reverse ($$);
}
- | UNSIGNED
+ | symbol_list_element
{
$$ = scm_list_1 ($1);
}
else
MYREPARSE (@4, $2, SCM_ARG, $4);
}
+ | EXPECT_OPTIONAL EXPECT_SCM function_arglist_nonbackup WORD
+ {
+ $$ = $3;
+ SCM res = try_word_variants ($2, $4);
+ if (!SCM_UNBNDP (res))
+ if (scm_is_pair (res))
+ MYREPARSE (@4, $2, SYMBOL_LIST, res);
+ else
+ MYREPARSE (@4, $2, SCM_ARG, res);
+ else if (scm_is_true
+ (scm_call_1
+ ($2, make_music_from_simple
+ (parser, @4, $4))))
+ MYREPARSE (@4, $2, STRING, $4);
+ else
+ MYREPARSE (@4, $2, SCM_ARG, $4);
+ }
| EXPECT_OPTIONAL EXPECT_SCM function_arglist_nonbackup full_markup
{
$$ = $3;
MYBACKUP (STRING, $4, @4);
}
}
+ | EXPECT_OPTIONAL EXPECT_SCM function_arglist_backup WORD
+ {
+ SCM res = try_word_variants ($2, $4);
+ if (!SCM_UNBNDP (res))
+ if (scm_is_pair (res)) {
+ $$ = $3;
+ MYREPARSE (@4, $2, SYMBOL_LIST, res);
+ }
+ else
+ $$ = scm_cons (res, $3);
+ else {
+ $$ = scm_cons (loc_on_copy (parser, @3, $1), $3);
+ MYBACKUP (STRING, $4, @4);
+ }
+ }
| function_arglist_backup REPARSE pitch_or_music
{
if (scm_is_true (scm_call_1 ($2, $3)))
// know the predicate to be false.
MYREPARSE (@3, $1, SCM_ARG, $3);
}
+ | EXPECT_SCM function_arglist_optional WORD
+ {
+ $$ = $2;
+ SCM res = try_word_variants ($1, $3);
+ if (!SCM_UNBNDP (res))
+ if (scm_is_pair (res))
+ MYREPARSE (@3, $1, SYMBOL_LIST, res);
+ else
+ MYREPARSE (@3, $1, SCM_ARG, res);
+ else if (scm_is_true
+ (scm_call_1
+ ($1, make_music_from_simple (parser, @3, $3))))
+ MYREPARSE (@3, $1, LYRIC_ELEMENT, $3);
+ else
+ // This is going to flag a syntax error, we
+ // know the predicate to be false.
+ MYREPARSE (@3, $1, SCM_ARG, $3);
+ }
| EXPECT_SCM function_arglist_optional full_markup
{
$$ = $2;
| context_def_mod STRING {
$$ = scm_list_2 ($1, $2);
}
+ | context_def_mod WORD {
+ $$ = scm_list_2 ($1, $2);
+ }
| context_def_mod embedded_scm
{
if (!scm_is_string ($2)
string:
STRING
+ | WORD
| full_markup
;
text:
STRING
+ | WORD
| full_markup
| embedded_scm_bare
{
;
simple_string: STRING
+ | WORD
| embedded_scm_bare
{
if (scm_is_string ($1)) {
STRING {
$$ = scm_string_to_symbol ($1);
}
+ | WORD
+ {
+ if (!is_regular_identifier ($1, false))
+ parser->parser_error (@1, (_ ("symbol expected")));
+ $$ = scm_string_to_symbol ($1);
+ }
| embedded_scm_bare
{
// This is a bit of overkill but makes the same
make_simple_markup ($1));
$$ = t->unprotect ();
}
+ | WORD {
+ // Flag a warning? could be unintentional
+ Music *t = MY_MAKE_MUSIC ("TextScriptEvent", @$);
+ t->set_property ("text",
+ make_simple_markup ($1));
+ $$ = t->unprotect ();
+ }
| embedded_scm
{
Music *m = unsmob<Music> ($1);
;
bass_number:
- UNSIGNED { $$ = $1; }
- | STRING { $$ = $1; }
- | full_markup { $$ = $1; }
+ UNSIGNED
+ | STRING
+ | WORD
+ | full_markup
| embedded_scm_bare
{
// as an integer, it needs to be non-negative, and otherwise
parser->parser_error (@1, _ ("markup outside of text script or \\lyricmode"));
$$ = $1;
}
- | STRING {
+ | WORD {
if (!parser->lexer_->is_lyric_state ())
parser->parser_error (@1, _f ("not a note name: %s", ly_scm2string ($1)));
$$ = $1;
}
+ | STRING {
+ if (!parser->lexer_->is_lyric_state ())
+ parser->parser_error (@1, _ ("string outside of text script or \\lyricmode"));
+ $$ = $1;
+ }
| LYRIC_ELEMENT
;
STRING {
$$ = make_simple_markup ($1);
}
+ | WORD {
+ $$ = make_simple_markup ($1);
+ }
| SCORE {
parser->lexer_->push_note_state (Lily::pitchnames);
} '{' score_body '}' {
return arg;
}
+SCM
+make_reverse_key_list (SCM keys)
+{
+ if (scm_is_true (Lily::key_p (keys)))
+ return scm_list_1 (keys);
+ if (scm_is_string (keys))
+ return scm_list_1 (scm_string_to_symbol (keys));
+ if (!ly_is_list (keys))
+ return SCM_UNDEFINED;
+ SCM res = SCM_EOL;
+ for (; scm_is_pair (keys); keys = scm_cdr (keys))
+ {
+ SCM elt = scm_car (keys);
+ if (scm_is_true (Lily::key_p (elt)))
+ res = scm_cons (elt, res);
+ else if (scm_is_string (elt))
+ res = scm_cons (scm_string_to_symbol (elt), res);
+ else return SCM_UNDEFINED;
+ }
+ return res;
+}
+
SCM
try_string_variants (SCM pred, SCM str)
{
// a matching predicate is always ok
if (scm_is_true (scm_call_1 (pred, str)))
return str;
- // a symbol may be interpreted as a list of symbols if it helps
+ // a key may be interpreted as a list of keys if it helps
if (scm_is_true (Lily::key_p (str))) {
str = scm_list_1 (str);
if (scm_is_true (scm_call_1 (pred, str)))
return SCM_UNDEFINED;
}
+ if (!scm_is_string (str))
+ return SCM_UNDEFINED;
+
+ // Let's attempt the symbol list interpretation first.
+
+ str = scm_string_to_symbol (str);
+
+ SCM lst = scm_list_1 (str);
+
+ if (scm_is_true (scm_call_1 (pred, lst)))
+ return lst;
+
+ // Try the single symbol interpretation
+
+ if (scm_is_true (scm_call_1 (pred, str)))
+ return str;
+
+ return SCM_UNDEFINED;
+}
+
+SCM
+try_word_variants (SCM pred, SCM str)
+{
+ // str is always a string when we come here
+
+ if (scm_is_true (scm_call_1 (pred, str)))
+ return str;
+
// If this cannot be a string representation of a symbol list,
// we are through.
{
if (unsmob<Music> (simple))
return simple;
- if (parser->lexer_->is_note_state ()) {
- if (scm_is_symbol (simple)) {
+
+ if (scm_is_symbol (simple))
+ {
+ SCM out = SCM_UNDEFINED;
+ switch (parser->lexer_->scan_word (out, simple))
+ {
+ case DRUM_PITCH:
+ {
Music *n = MY_MAKE_MUSIC ("NoteEvent", loc);
n->set_property ("duration", parser->default_duration_.smobbed_copy ());
- n->set_property ("drum-type", simple);
+ n->set_property ("drum-type", out);
return n->unprotect ();
}
+ case NOTENAME_PITCH:
+ case TONICNAME_PITCH:
+ // Take the parsed pitch
+ simple = out;
+ break;
+ // Don't scan CHORD_MODIFIER etc.
+ }
+ }
+
+ if (parser->lexer_->is_note_state ()) {
if (unsmob<Pitch> (simple)) {
Music *n = MY_MAKE_MUSIC ("NoteEvent", loc);
n->set_property ("duration", parser->default_duration_.smobbed_copy ());
projects / lilypond.git / commitdiff