There are three homeworks. Two are case studies: one involves GNU Emacs, and one a large free-software program of your own choice. The third is to be determined, probably something involving microservices. Homeworks are intended to be independent of each other. The free-choice homework can be done by yourself, or in a pair. The other homeworks are solo.
Each project should use the following general rules.
All work (including documentation, lab notebook, etc.) should be saved in a version control system, such as Git, Mercurial or Apache Subversion.
A change log should be kept, to reflect every change to programs, documentation, etc. Whenever you make a change to your project, you should update the corresponding change log. For new projects, or projects that do not already have a change log, we suggest the GNU ChangeLog format; see an Emacs ChangeLog for an example. For other projects you should use the change log format of that project. It is fine to generate a change log automatically from your version control system's commit messages so long as these messages are suitably informative.
A news file should be kept, to reflect every change that users probably care about. This is an abstracted version of the change log. (Some projects may not make any changes that users care about; these projects need not have a news file.) See the Coreutils NEWS for an example.
Students will present their interim and final results in in-class presentations, shortly after the midterm and just before the end of the class, with exact schedule to be determined. Please consult the resources for oral presentations for advice about how to improve your presentations.
Each student is expected to contribute significantly to the homework. You may share ideas and discuss general principles with others in the class, and obviously you may share work with other project members. With the advance permission of the instructor, you may even share work with members of other projects. However, all the code that you submit as your own must be your own work. Please see Grading for more details. Consult the TA or the instructor if you have any questions about this policy.
Your programs must behave robustly. Among other things, this means they must avoid arbitrary limits on the length or number of any data structure, including symbols, strings, and line length. It is OK to impose a non-arbitrary limit, e.g., because your computer runs out of memory or because of the limited range of the Java int type, but it is not OK to impose an arbitrary limit, e.g., a limit of at most 255 characters in a symbol.
When working on a project, please stick to coding styles that the project already uses rather than inventing your own style, as this saves work for everybody involved. If it is a greenfields project please use a common coding style.
In the case studies, keep a log in a file log.txt of what you do so that we can see what you did and so that you and we can reproduce the results later. This should not merely be a transcript of what you typed: it should be more like a lab notebook, in which you briefly note down what you did and what happened. If you prefer a fancier format than plain text, feel free to use that format; but plain text is OK.
This will involve adding a feature to GNU Emacs and making sure that it works.
The new feature will support Perl-compatible regular expressions (PCREs). Emacs uses regular expressions (REs) extensively. Although Emacs has a longstanding RE syntax that needs to be supported and should be the default, some users prefer the regular expression syntax of Perl, and we'd like Emacs to support this syntax as well.
In principle you could implement PCRE from scratch, or by translating PCREs to Emacs REs. However, you're going to use a library to support PCREs, namely PCRE2, first released in 2015.
The first step of your assignment will be to familiarize yourself with GNU Emacs internals and with PCRE2. Start by downloading a copy of the Emacs development sources, from its master branch. You will be expected to keep up to date with the master branch during your development, by merging its changes into yours.
Keep a lab notebook as described above, and submit it as part of your work.
The first assignment will be to implement GNU Emacs numeric regular expressions.
More details will come later.
This will involve adding a feature to a software package of your own choice. The package must be reasonably large and actively maintained and use an open-source license, and the feature should be a good one that is not already in the package. Your first step will be to choose a package and a feature to add, and propose it to use for adoption. You can make multiple proposals, and we'll review them and tell you which ones we like.
Keep a lab notebook as described above, and submit it as part of your work. The first part of your notebook should describe the sorts of packages you'd like to work with, and why you chose the package that you chose.
More details will come later.
TBD