Notes

This page is mainly intended as an alternative to the casa-staff mailing list where optional things to make CASA development easier can be put. It does not replace CASADevelopmentBuildCycle, CASADeveloperHowTos (mainly how to convert a tool to XML), CASARegressionTesting, or other pages that I'm not even aware of. Tips for using CASA can be found at CASA Scripts, Tips, and Tricks.

Mixing rsync (and/or unison?) with svn

Most of us keep multiple copies of the code tree, and either only checkin from one copy, or use svn, and only svn, to keep things in sync. However, while traveling you might find yourself wanting to update the copy on your laptop when the code should not be checked in (because it would break the build). Rsync and unison work well to copy code over, but if you run svn status afterwards you will find many "locked" directories ( L in the third column) and possibly other problems. Worse, svn up (and presumably svn ci) won't work.

To get your tree back in compliance with svn,
  1. svn cleanup (may take a few minutes)
  2. svn up
  3. (Optional, but a good idea) svn stat You will likely find some uncontrolled things, typically because they have been renamed in the repository and should be deleted in your local copy.

-- RobReid - 2009-03-27

Maintaining a clean code tree in general

Mere humans may create files and forget to svn add them. Then when they checkin anyone who runs svn up after that will probably have a non-working build. Thus you should always run svn stat just before checking in, to look for uncontrolled files and run svn add if necessary. Unfortunately there are often a lot of uncontrolled files which should not be svn added, and it is easy to lose the ones which should be added in the shuffle. Even if you have a silicon brain with multiple svn backups, after svn up you have to deal with (or ignore) "ghost files" in the old places when others mv files to new places.

NOTE: svn stat | grep -v ^\? works great for filtering out uncrolled files - DaveMehringer

I wrote a little perl script, vcs to filter out, rm, or mv away the distracting files, and svn add the remaining ones before checking in. So, if you use vcs instead of svn stat, and vcs -c instead of svn ci, you will both get a cleaner (IMHO) view of your code tree, and be less likely to mess up the repository. It is slightly tuned for $CASAROOT/code/, but is easily reconfigurable. For example, drop this .vcsrc in your $CASAROOT/casacore directory, and use vcs -f $CASAROOT/casacore/.vcsrc when working in there. Warning: a malicious programmer could insert their own .vcsrc into the repository, which vcs could eval after an svn up. It is much better, security-wise, to keep ".vscrc"s outside of the code tree. This risk is however not any different from using makefiles from the repo without reading them first.

Finding definitions of classes, etc.

IDEs have been doing this (or trying to) for years, but my experience was that getting existing packages to deal with CASA's directory structure was difficult or impossible, and it didn't get any easier with the casacore switch. Kumar's had good (but not perfect with *.tcc) experience with Source Navigator, but I use a combination of emacs' code browser (ecb) and my own perl script, lsrc. I have hammered on lsrc until it works well enough for me in emacs, but I think/hope that is useful with other editors as well. "Works well enough for me" means that there are still some improvements which could be made, but I haven't felt the need to make them myself.

lsrc caches its database, so it is a little slow to run the first time but runs quickly after that. It should automatically update the db as needed when the code is changed - the only times I've needed to rm the db and start over are after =cp=ing it from another computer or making a large change to lsrc.

ecb is impressive, but not perfect. Some of the impressive things are when you're working on something outside CASA, or on an HTML file, and it surprises you with something useful. The most annoying thing is that it tends to lurk in the background and can slow things down with its constant analysis of everything, just like any other IDE. It can be turned on (or off) with M-x ecb-(de)activate. The second most annoying thing is how much screen space it takes up. Figuring out which windows to use and how big to make them is a matter of taste.

Simpler things which did not work to my satisfaction:
  • plain old tags (i.e. etags, (exuberant) ctags)
  • cscope
  • ecb by itself
  • imenu

It's possible that these could be made to work with CASA, and that I just don't fully understand their subtleties.

RunningDebuggers

Make tasks throw an exception rather than exiting with just an *Error* message:

If you have long scripts that use tasks and sometimes it fails with exception in between and the script proceed on its "petit bonhomme de Chemin" as if nothing happened

you may wish to set

__rethrow_casa_exceptions=True

before launching your script

As of release 3.4 all tasks now by default traps exceptions and exit silently

So this is a pain when developing python tasks etc as syntax errors or typos are not reported.

You are thus advised to add the above line in your

$HOME/.casa/prelude.py

file (or create one if it does not exist)
Topic revision: r10 - 2013-02-13, PatrickMurphy
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback