Home
•
Course Info
•
Schedule
•
Mini Projects
•
Results
•
Resources
•
Exam
•
News
Center
Master Program
Center
Home
Courses
People
Projects
Page
Edit Page
Rename Page
Attach File
Printable
Wiki Source
More ...
Web
Recent Changes
Notify Service
News
Page Index
Search
More ...
Wiki
About TWiki
Text Formatting
Registration
Change Password
Reset Password
Users
Groups
Log In
or
Register
Mini Projects
Cco
---++ 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. ---++++ 2010/2011 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 <code>README</code> 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 <code>README</code> file should list the team members involved and should contain detailed instructions on how to build and use your programs. * Use 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. ---+++ Criteria and grading Grading of the 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. In other words: if you choose an implementation with difficult to explain parameters and structures, which you also do not (and most likely cannot) explain, then this will guarantee a low grading. ---+++ Working in teams 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 Each team reviews the work done by other teams on a weekly and per lab exercise basis. At the lab session after the first lecture of the week we'll start by peer reviewing: each team has written on a single (or somewhat more, if necessary) A4 page their design for the solution of the lab exercise, available in printed form so another team can review it. That other second team reviews the design, asks for clarification, finding potential problems and limitations, etc. The purposes are (1) to start early with writing design documentation and think about the lab exercise, (2) to understand the problem better by looking at somebody else solution, (3) to facilitate class discussions about various ways to solve the problem at hand. Similarly, each lab exercise submission is peer reviewed, taking into account the grading criteria, leading to written feedback for both the reviewed team. Both this feedback and the submitted solution are used by the teacher for grading. #MiniProjectA ---++ 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]] #MiniProjectB ---++ 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]] #MiniProjectC ---++ 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]] #MiniProjectD ---++ 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]]
