ACEDB User Group Newsletter - April 2002

If you want to have this newsletter mailed to you or you want to make comments/suggestions about the format/content then send an email to acedb@sanger.ac.uk.

This month sees some new features to support driving of acedb programs from scripts, some Gene Finder changes and as usual some bug fixes.

General News

We continue to work on the introduction of the new SMap code which is taking some time as it has many anticipated and many unanticipated (!) effects on the FMap code in particular.

New Features

New "Save" and "WriteAccess" commands/options

Previously users have had more control over saving and write access when using xace (e.g. "Save session and keep write access") than with the command line tace and giface programs. New options have been added to the "Save" command and a new "WriteAccess" command has been added:

Save : [-drop | -regain]
    Save current state otherwise the system saves every 600 seconds
       -drop   (default) drop write access after saving
       -regain regain write access after saving

Writeaccess : [-gain | -drop [save | nosave]]
    Set write access status
       -gain (default) get write access
       -drop lose write access, with or without saving

These commands are particularly useful for scripts that need to update a database and perhaps need to hold on to write access while parsing in several files of data.

New options for giface commands to give more power to xremote

The giface program allows the creation of "virtual" displays (e.g. fmap, gmap) and then the dumping of those displays in various formats, e.g. GFF, postscript, etc. Perhaps less well known is that xace can be driven by the same commands via the xremote program distributed with AceDB.

For instance:

xremote -remote 'gif ; seqget bA314N13 ; seqdisplay'

Will get you an FMap of clone bA314N13 displayed by xace (you must have xace running before you issue the xremote command.

This mechansim is used as a core part of the "lace" annotation tool maintained by James Gilbert James Gilbert <jgrg@sanger.ac.uk> for the human annotation project at the Sanger Institute.

The new options include:

seqdisplay ..... [-new] [-title title]
     Works on current sequence, use gif or ps to actually dump the display
        -new     make a new sequence, current one is preserved (for use only with xremote currently)
        -title   give your own title to the sequence

seqrecalc
     Causes the sequence to be recalculated for the active graph

You could for example use the new commands/options to construct a script which:

1. Starts up an xace for the user, and then automatically displays a sequence in an fmap:

   xremote -remote 'gif ; seqget sequence_name ; seqdisplay'
   

2. Adds new data into the database and gets the fmap to recalculate and show the new data by:

   xremote -remote 'gif ; seqrecalc'
   

3. Replaces the sequence in the fmap with a new sequence:

   xremote -remote 'gif ; seqget new_sequence_name ; seqdisplay'
   

4. Displays a new sequence in an entirely new fmap (which becomes the current fmap, the existing current one is preserved):

   xremote -remote 'gif ; seqget another_sequence_name ; seqdisplay -new -title "Super New Sequence'
   

March monthly build not available.

Apologies, once again there was no build this month due to the major SMap development work.

Articles

Gene Finder changes

Kevin Howe <klh@sanger.ac.uk> has made some changes to the Gene Finder code (originally written by Phil Green of Washington University Medical School) which while not strictly affecting acedb are worth documenting here (most of the changes affect the stand alone version of the gene finder code).

Kevins comments:

You can do a diff on the file yourself to see what I've changed. The standalone-only stuff I've protected with "#ifndef ACEDB", but I'll just summarise the other changes here:

1. The array "cumVec" is now double instead of float (and this has some knock-on effects in places where this array is used/passed, parameter types etc). This is because the float precision is inadequate for sequences more than 10kb or so. You may want to change this back.
2. I've changed the constant SEGSCORECUTOFF from a #define to a static float. This is so that the value can be modified by a command-line option in the standalone version.
3. The main calculation of the coding segments and genefinder features in "aceFeatures" and "aceSites" is now protected with checks that that tables for each site-type are non-null. This will have no impact in ACEDB, because the tables are always non-null, but I've extended the standalone version to be more flexible in what it expects in the tables file. If you don't want ATG predictions, then you can make a tables file with no ATG tables, and the code will now happily not try to predict ATGs.
4. In aceMaxSegs, there was a mistake which meant that some GF_CODING segments were calculated in the wrong frame, which I've fixed. In aceFeatures, I also added a fix which ensures that coding segments that bridge a stop codon are broken into two segments, one either side. I discussed this one with Richard and he agreed that this is the now the correct behaviour.

Bugs Fixed

Inappropriate "Show As" actions

The code to decide what to do when a user tried to display an object from the keyset window when the "Show as" display type was incorrect did not always work very sensibly or, in some cases, did not work at all.

The code to decide what to do when there was an object/display type mismatche was scattered across some 15 files which compounded the problem. All the code to choose what to do is now in display.c and takes a consistent series of steps to cope with this problem, ending with the Tree display if no other appropriate display can be found. In addition the code will now warn the user when the object simply cannot be displayed.

Buglet in restriction dialog for Fmap

The search pattern in the dialog box is now also reset to blank when the user clicks the "clear" button.

Bad bug in the GFF dumper.

A change in the way the strings that hold an objects name are handled caused the GFF dumper to reference deallocated storage when printing out the objects name, now fixed.

Developers Corner

If you wish to make comments/suggestions about any of the below, please mail them to acedb@sanger.ac.uk

Replacing bIndexFind() with bIndexTag()

The bindex package in acedb provides a call to use the index to test whether a particular tag exists in an object:

BindexFindResult bIndexFind(KEY originalKey, KEY tag) ;

But there is a trap for the unwary here in that the call can return one of three possible values (BINDEX_TAG_ABSENT, BINDEX_TAG_UNCLEAR, BINDEX_TAG_PRESENT) and its very easy to forget this and write code that assumes that a Boolean value is returned:

if (bIndexFind(key,tag))

This call will sometimes return BINDEX_TAG_UNCLEAR and sometimes BINDEX_TAG_PRESENT with consequent confusion in the code following the test.

In fact Jean had already added some functions (keyGetNNN) to bssubs.c to use bIndexFind() but then open the object and look for the tag if the return from bIndexFind() was BINDEX_TAG_UNCLEAR. These calls returned an unambiguous Boolean value to indicate whether the tag was present or absent.

These calls have now been renamed and moved to bindex.c as it seems more logical/obvious for them to be with bIndexFind, they are:

BOOL bIndexTag(KEY key, KEY tag) ;

returns TRUE if tag is found in object key.

BOOL bIndexGetKey(KEY key, KEY tag, KEY *key_out) ;

returns TRUE if tag is found in object key and will return the key following tag in key_out if key_out is non-NULL.

April monthly build not available.

Apologies, once again there was no build this month due to the major SMap development work.