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
(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
afterwards you will find many "locked" directories (
in the third column) and possibly other problems. Worse,
) won't work.
To get your tree back in compliance with svn,
svn cleanup (may take a few minutes)
- (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.
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
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
, 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
, but is easily reconfigurable. For example, drop this .vcsrc
directory, and use
vcs -f $CASAROOT/casacore/.vcsrc
when working in there. Warning:
a malicious programmer could insert their own
into the repository, which
could eval after an
. 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
) 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.
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
. 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.
- ecb by itself
It's possible that these could be made to work with CASA, and that I just don't fully understand their subtleties.
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
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
file (or create one if it does not exist)