You are here:
(02 Dec 2013,
---++ General project information ---+++ Submitting ---++++ General info * See the CourseSchedule for deadlines. * See the CourseResults for grading as it appears during the course. * See the CourseResources samples. ---++++ 2013/2014 edition All should be submitted via the submit system at http://www.cs.uu.nl/docs/submit/ as a single zipped file archive on the relevant deadline, 11:59pm. ---+++ Your submission * The source code of your mini project implementations which must include * UUAG sources. * Haskell sources _not_ generated by the UUAG system. * Documentation in pdf format and the original text for documentation. * A =README= file (see later) * All the code of your implementation must be documented; you must explain the design of your solution, the interface of functions, the use of attributes (when attribute grammar is used). Documentation must be in pdf format. Use the following tools for documentation: * [[http://www.haskell.org/haddock/][haddock]]; most appropriate for generating online doc for Haskell code. * [[http://people.cs.uu.nl/andres/lhs2tex/][lhs2TeX]]; most appropriate for literate programming style for arbitrary program code, generating latex documents describing your code. See also CourseResources. * !TeX tools. * In the <code>README</code>file (in plain text format) you explain * what functionality you have implemented, * which versions of which compilers are needed to build your code, * where the starting point of the design documentation is to be found. * Your =README= file should list the team members involved and should contain detailed instructions on how to build and use your programs. * Use cabal or a makefile for the (low level) building instructions. The makefile by defaults builds the programs and has a separate entry for building the documentation. * Also see the project descriptions for additional requirements. ---+++ <span style="background-color: transparent; line-height: 1.1em;">Working in teams</span> All projects are done in teams of two participants. You are free to discuss at liberty about design and implementation ideas (because the necessary explaining helps you understand), but you may not share between teams the code and explanation you submit and work on (this is considered fraud, and it does not help to _really_ understand), with the exception of supporting material (such as makefile). A team size of two helps you because you both have someone available to check your ideas with, yet at the same time prevents you from escaping the actual work which needs to be done. The latter is important, because doing the mini projects constitutes the major part of becoming familiar with the course material and in that way is the preparation for the exam, which is a check on having acquired the knowledge explained in the course. Submission of work is done per team. ---+++ Peer reviewing, self reviewing, and lab exercise/mini projects grading For each lab exercise a team reviews its own submission and the submission of another (randomly chose) team. A review must be submitted as well. The criteria below are to be used for these reviews. Each review is done in the week immediately following the corresponding lab exercise deadline. The length of the review is undetermined as it will depend on a particular submission, but usually it will be an A4 page of text. Each review should include a grade. The final grade for each lab exercise depends on the difference between your own grade and the one provided by the review from another team. If the grades differ less or equal than 1 point, the mean of the two grades is used, otherwise the teacher will determine the grade using the submissions as well as the reviews. The purpose of this system is to (1) learn to self reflect on your own work, (2) use (& possibly come up with additional) criteria, (3) be on the position of judging work done by others (as this needs to be done in many academic positions: teacher, paper peer-review, proposal judging, ...). ---+++ Judgement criteria Grading of the lab exercises/mini projects will be done using the following criteria, on top of constraints mentioned earlier on this page: * The explanation of your design and implementation must be clear enough to not need actual inspection of implementation code for understanding the design and implementation. * The implementation must compile & run without errors, and pass tests as specified by the project description. * The design and implementation must be the simplest possible to satisfy the requirements of the project. However: * <span style="background-color: transparent; line-height: 22px;">Design and implementation can be too simple, causing some requirements not to be met. </span><span style="background-color: transparent; line-height: 22px;">Or it can be more complex because additional requirements are met. In both cases a rationale should be available. Both 'not meeting requirements' and 'overly complex' can have a negative effect on grading.</span> * <span style="background-color: transparent; line-height: 22px;">Alternative designs not necessarily are better or worse in terms of fulfilling the requirements, but be better or worse in criteria like: portability, maintainability, user interface (i.e. error reporting), etc. Although important for learning about different approaches, effect on grading is minimal.</span> In other words: try to make your solution as clean, simple, understandable as possible, providing the documentation necessary to make reviewing as easy as possible. <a name="MiniProjectA"></a> ---++ Mini Project A: <nop>BibTeX2HTML The aim of this mini project is to implement a suite of small command-line utilities for processing bibliographic databases in <nop>BibTeX-format and producing logical documents in HTML-format. [[%ATTACHURL%/cco-project-a.pdf][Project description]] <a name="MiniProjectB"> </a> ---++ Mini Project B: T-diagrams The aim of this project is to implement a typed domain-specific language for T-diagrams. [[%ATTACHURL%/cco-project-b.pdf][Project description]] | [[%ATTACHURL%/tdiagrams-0.0.4.tar.gz][Project distribution]] <a name="MiniProjectC"></a> ---++ Mini Project C: Static-link optimisation The aim of this mini project is to implement a small optimisation in a supplied code generator. [[%ATTACHURL%/cco-project-c.pdf][Project description]] | [[%ATTACHURL%/imp-0.0.5.tar.gz][Project distribution]] <a name="MiniProjectD"></a> ---++ Mini Project D: Type reconstruction The aim of this mini project is to reconstruct explicit type annotations from implicitly typed lambda-terms. [[%ATTACHURL%/cco-project-d.pdf][Project description]] | [[%ATTACHURL%/fun-0.0.4.tar.gz][Project distribution]]
ore topic actions
Topic revision: r17 - 02 Dec 2013,
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding UUCS?