---

Getting the code

• First, get the Calvin software repository:
  • sign up to the ECDF subversion service at https://registration.ecdf.ed.ac.uk/svnreg/userreg.php (you need to be logged into EASE in order to be able to register to ECDF).
  • give Davide your username (uun) and he will grant you read and write permissions.
  • Use your ECDF [uun, password]  to access the repository https://svn.ecdf.ed.ac.uk/repo/inf/calvin
• Users without EASE account (e.g., external collaborators) have to register to EASE friends at https://www.ease.ed.ac.uk/friend/. Their uun will correspond to the e-mail address used for registration.

 

Your development code

• Your personal code belongs in calvin/matlab/yourname_matlab/ ( e.g. vitto_matlab). You will have to create this folder at the beginning.
• This folder is meant to be your local workspace, for you to debug and experiment. This means you should commit very frequently, even when the code is not stable or it does not run at all.  As a rule of thumb, at least commit all changes at the end of the day.
• Before implementing an algorithm (e.g. k-means clustering), see if it is already available in the software repository, in directory released.
• If there is a function/method you want to use, do NOT copy it to your own folder. Instead, add the path to your MATLAB environment.
• The repository is for storing code. It is not for putting the data required by your experiments. It is OK to add small amounts of data required by demos or unit tests
• If you implement something that might be useful for other people, move it to the /calvin/matlab/released folder (see below)

 

Adding code to the released folder

• The released folder is for stable code that can be safely shared across Calvinees.
• Once you have some robust code that can be reused by other Calvinees, move it into the released folder
• Group the functions you plan to move into released into a directory with a proper name (e.g. k-means, surf, etc.)
• Comment the top level functions. Explain what the input and output arguments are, and what the function does.
• Write a README explaining how to use the code. This must contain a list of all the packages your code depends on
• Add a demo.m file, together with the test data required by the demo. This should show a simple usage of your code. Make sure it works!
• Test the code properly and extensively on more than just your machine. Asking other people to try it is a good way to debug it
• Make sure the other Calvinees are aware of the code you added to released.
• Do not use absolute paths. Avoid relative paths whenever possible
• If you need to pass a path to a function, use a data structure. For example data.cachedir = ‘/disk/scratch/workspace/voccache/’;

• Reuse the same data structures across functions in your code. This makes it easier for the user. For example

• Do the same for parameters. When your function requires a lot of input parameters, group them into a data structure

• Choose informative names for your functions. It is ok if the function name is long. This makes it easy to understand the purpose of the function, and reduces the chances of name clashes. If you have a function for training DPMs on Pascal, call it trainDPMonPASCAL, not just train
• If you find a bug in released, do not fix it yourself. Contact the author. If the author has left, then fix it yourself.