Personal tools
You are here: Home / cmgui / Wiki / Useful tips from Peter
Navigation
Log in


Forgot your password?
 

Useful tips from Peter

Introduction

This page contains various tips I have found useful that I have not yet found a better place for. I intend to gradually move information from this page to more appropriately named pages when I have the time.

Mac tips

Setting up a zinc development environment

How to set up a local bin directory

Cmgui library maintenance

Building ubuntu packages from source

Building sample npruntime plugins

Which Ubuntu version

To see which version of ubuntu you are running type 'lsb_release -a'

General info about your computer and the operating system can also be found by running 'uname -a'

Changing default os to boot

Edit the file '/boot/grub/menu.lst' and change the value for the parameter 'default' to be the list item you wish to boot by default. The list is numbered from 0. The file is well commented so explains what all the settings do. You will need to use sudo with a text editor like vi, or gksudo with a graphical text editor like xemacs. eg at the command prompt type 'gksudo xemacs /boot/grub/menu.lst', enter your password, edit the file and save it. Note that when a new kernel or operating system is installed, it will get added to the list. This may effect the numbering and screw up your default setting, depending on where the entry is inserted on the menu.lst file. You can get around this problem by setting the parameter 'updatedefaultentry=true'. This way the number you have set as the default is updated if you get a kernel upgrade inserted above your default os. You can also set grub up to default to the last booted os. The 'default' parameter needs to be set to 'saved' and the 'savedefault' command must be added to each boot entry for this to work.

Setting up default environment variables in bash

See Setting environment variables in bash

Useful search tool

I use grep a lot but it is a pain to use with version controlled sources as you get a heap of matches you don't want. You can of course use find or a grep command to ensure you are only searching for files of the right extension but there is another way which is more convenient.

I discovered this little tool called ack, it works very nicely and also does highlighting. http://petdance.com/ack/

Other visualisation tools

Here is a list of some other tools which have some of the capabilities of cmgui

Visualisation and modelling

Medical image visualisation

Adding filters to zinc

See the Adding filters to zinc link.

Using filters

See Sigmoid filter

Writing ITK standalone executables

See the Writing programs that use ITK

Wireless access using linux

See the Wireless access using linux link.

Wiki formatting

For formatting wiki pages using structured text see http://www.zope.org/Documentation/Articles/STX

For formatting using restructured text see http://docutils.sourceforge.net/docs/user/rst/quickstart.html

Indentation is very important and does not always provide the effect expected. Always use the preview button before saving a page.

Note that there are several page types that can be selected when editing the wiki. If your structured text does not work the way you expect check that the page you are editing as structured text selected as its page type.

To add an image to the wiki, use the add to folder drop down menu towards the top right area of the wiki. You can then use a url to point to the image location, like so:

http://www.cmiss.org/cmgui/wiki/TruncatedCone/view or you can get the image to display directly within a wiki page. See Adding Images to the wiki page for how to do this.

General debugging

Google is your friend. Google any errors first before bugging someone about how to deal with them.

The ddd debugger can be easily started up with firefox by typing 'firefox -g' at a console prompt. ddd is a gui for gdb and is a good tool to use if you get stuck and need to step through your code line by line. Here are some Tips for using ddd.

Source control

svn and cvs have a very similar command line interface. To check in a file to source control using subversion

svn add filename
svn commit -m 'your useful message here' filename

CVS is identical except svn is replaced with cvs. Note when running the code above you will be asked for your password. The subversion password should be different from your other passwords for security reasons. Tiong is the person to see if you forget your password. See email from Tiong for memo on how to change passwords.

To see which files have been modified in a directory try 'svn status | grep ^M'

To commit files modified in the last day with a .cpp extension use

find . -mtime -1 -name "*.cpp" -exec svn commit -m 'added help text to option_table' {} \;

When updating using cvs, if you want to prune any deleted directories and add in any newly create ones use

cvs update -Pd

If adding image files to the cvs repository, png files are preferred to jpg as they are non-lossy. When adding an image file you should add it as binary

cvs add -kb myfile.png
cvs commit -m 'added image' myfile.png

If you accidently commit an image file on linux as ascii instead of binary it will not be readable on windows. The file can be flagged as binary as follows

cvs admin -kb myfile.png
cvs update -A myfile.png

If you want to rename a file and keep its history, you can do so in subversion using the svn move command

svn move foo.c bar.c

Note that this only works if bar.c does not exist. If bar.c does exist and is a file rather than a directory, you will get an error message complaining that bar.c is not a directory. If bar.c was a directory the file would be moved into that directory. This is because the move command can be used to move files or rename them.

Defining fields

Consider a matrix A:

    1 0 0
A = 0 2 0
    0 0 3

How to do a matrix multiplication of the field named coordinates by a 3x3 matrix A:

gfx def field A constant 1 0 0 0 2 0 0 0 3
gfx def field B matrix_mult number_of_row 3 fields A coordinates

How to calculate the inverse matrix field:

gfx def field A constant 1 0 0 0 2 0 0 0 3
gfx def field inv matrix_invert field A

Profiling cmgui

Profiling is a tool which allows you to tell which functions are taking up the most cpu time during program execution. To profile an executable you first need to compile it using the -pg option. Then you run the program and a data file called gmon.out will be produced. If you run gprof with the executable name it will load the generated data file and use it to write out useful profiling information. More detail on this process is described below.

1. To compile with the -pg option you will need to edit the file $CMISS_ROOT/cmgui/source/common.Makefile Fortunately the lines you need to add -pg to are already in existence, they are just commented out. Go through the file and uncomment all the -pg options lines (commenting out the normal line below it).

  1. Build cmgui. In the $CMISS_ROOT/cmgui directory type 'make cmgui'. You may need to touch a source file to get it to recompile if you have not edited anything else.
  2. Run cmgui. When cmgui quits a file gmon.out will be written to the current directory.
  3. To use gprof your executable and the gmon.out file need to be in the same directory. Copy one if necessary so that they are both in the same directory
  4. The syntax for running gprof is: 'gprof executable_name'. The results of processing the gmon.out file for the executable is written to standard out. Running gprof can take a minute or two for complicated programs and the output can be quite large so I suggest redirecting it to a file: 'gprof cmgui > profile_info.txt'

More information on gprof can be found here: http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html

Running cmgui examples

If you have the CMISS_EXAMPLES environment variable set you can run an example from anywhere by using the following syntax

cmgui -example path/to/example

Eg 'cmgui -example a/volume_texture'

To check your CMISS_EXAMPLES directory is set try typing 'env | grep CMISS' at a prompt to see if it comes up. Note that if you have only checked out some examples on your local machine and have CMISS_EXAMPLES pointing to this local directory you can only run examples that have been checked out.

Another way of running cmgui examples is to copy the example files from the example tree (or grab the tar file for the example from the list of examples on the website). You can then navigate to the cmiss_input directory for that example and run it by typing 'cmgui com_file_to_run.com'

Note that most examples use the $example variable when running to specify the location of the example directory. If you run the example directly from within the cmiss_input directory then you should have no problems as $example defaults to "."

One problem you may have is when reading exnode and exelem files there extensions must be specified! The following line will not work 'gfx read node $example/bob', it needs to be 'gfx read node $example/bob.exnode'

Updating cmgui examples

When you update an example you should check that it still passes the example test. Note that even if your example does what you want it will still fail if the output log file cmiss_test.log differs from the one in cvs. If this is the case then the "model answer" cmiss_test.log output file will need to be updated. The easiest way to do this is to run the test on your example, keeping all generated files and then replace the "model answer" log file with the one the output generated by your test.

For example, to run the example a/commands with cmgui and keep all generated files (including the output log) I type:

$CMISS_EXAMPLES/common/cmiss_type1/test_tree.pl -p cmgui -e a/commands -k

The output log file for each operating system and executable tested will be written to a separate directory. Eg when testing i686-linux with cmgui the cmiss_test.log file will be written to the directory:

$CMISS_EXAMPLES/a/commands/output/i686-linux/cmgui

In this directory there will also be log files indicating the result of comparing cmiss_test.log against the model answer.

If you are happy for your generated log file to be the new model answer you can copy it over to directory containing the model answer. There are separate directories for each operating system but if the log file generated will be the same for all operating systems you can place your new model answer in the generic directory:

$CMISS_EXAMPLES/a/commands/testing/diff/generic

Updating web page content for examples

The webpage content is generated on bioeng22 every night. Each example has a listing generated for it which includes information about what tests passed/failed and when. This text is generated from the files in the "output" directory.

If you wish to update the contents of an example on the web before the overnight build you can do so by logging onto bioeng22 as cmiss and running the html_tree.pl script. To update example a1 you would type

ssh cmiss@bioeng22
$CMISS_EXAMPLES/common/cmiss_type1/html_tree.pl -e a/a1

It is also possible to update all the a examples by specifying '-e a' rather than '-e a/a1'.

If there is test output that is no longer required, you can manually remove the appropriate files from the output directory and regenerate the web page for that example. For example, to remove the testing infor about cmgui-wx-debug-valgrind from example a1 you can do the following

ssh cmiss@bioeng22
cd /hpc/cmiss/examples/a/a1/output/i686-linux
rm -r cmgui-wx-debug-valgrind
$CMISS_EXAMPLES/common/cmiss_type1/html_tree.pl -e a/a1

To do all the examples is a bit trickier, as all the i686-linux directories need their cmgui-wx-debug-valgrind directory removed. I'll see if I can come up with an easy way of doing this.

subtopics: