# ACEDB User Group Newsletter - July 2001

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 the introduction of a long requested feature, namely an interruptible Fmap, there are new display tags for the Grid display, an article on circular object references and once again the problem of programs running out of stack space rears its ugly head. As usual there are a number of bug fixes as well.

## New Features

### Oh NO, I meant to click "View as text"

Well we all do it, you click on an object in the `"Keyset"` or `"Tree display"` windows and before you can do anything about it `xace` is churning and churning and the busy cursor just won't go away....sigh. The usual cause of the problem is that you have clicked on a "Sequence" object that either has a huge number of children or some very big parents (just see how programs mimic life...). Xace is busy opening, examining and closing a large number of objects and allocating large amounts of memory as it tries to prepare an `Fmap` of a large section of sequence.

Well in the latest monthly release you can now press the `"F4"` key to stop the Fmap display. When you do this a dialog box will appear after a couple of seconds that will give you some idea of what Fmap was doing when you interrupted it and allow you to choose whether to stop or continue. If you decide to stop, xace will display the object using the `"Tree display"` which is probably what you would have done anyway.

Currently Fmap will show it has been interrupted at one of the following stages:

- "Getting the DNA" (constructing a unified section of DNA for the sequence)
- "Constructing virtual sequence" (collecting together all the information e.g. homols, gene predictions etc., for the sequence)
- "Finding coding" (finding all the CDS coding in the sequence)

In addition to making Fmap interruptible, Fmap will now also initially check the size of sequence you have asked to display and if the sequence is large a dialog box will immediately give you the chance to stop. Once again the object will be displayed using the `Tree display` if you decide to you don't want the Fmap.

### New Grid display options

A user recently made two requests for enhancements to the Grid display:

- tags to set the size of the grid boxes
- a tag to switch from one label per sub-block of boxes to one label per box.

The new monthly release has support for these, the following changes have been made:

New tags have been added to the ?Grid class:

    Square_size UNIQUE Float UNIQUE Float // Total size of box and surrounding space,
    				      // (default = 2.0 1.0)
    Box_size UNIQUE Float UNIQUE Float    // Size of box, cannot be bigger than
                                          // Square_size dimensions (default 0.9 0.7).
    Label_per_box                         // Do a label per box rather than a label
                                          // per "Lines_at" sub-block.

With "Square_size" you can control the size of the square that the box is drawn in, and with "Box_size" the size of the box itself. This allows you to specify a small box with a large surround, a large box with a small surround and so on. You can modify the sizes interactively from the grid display main menu so you can see how different settings look.

If you specify the tag "Label_per_box" with one of the labelling options, e.g. "Labels UNIQUE A1_labelling", then grid will display the labels one per box rather than one per block of boxes.

Originally the ?Grid class contained a "Size" tag:

    Size UNIQUE Int UNIQUE Int
                          // idea is to give box size here

This tag was never in fact supported by the code and has been withdrawn.

Remember that to use the new tags you will need to get both the code and the definition of the ?Grid class from the sample wspec/models.wrm that come with the new monthly build.

## Articles

### Sequences that point to themselves

It's a perennial problem, you make a sequence object and it was supposed to have a different parent, or perhaps no parent at all, but somehow it ends up being its own parent. Here's an example:

    Sequence : "my_parent"
    Source "my_parent"
    Subsequence "child" 1 110000

    Sequence : "child"
    Source	 "my_parent"
    Source_Exons	 1 55
    Source_Exons	 8893 9213
    Source_Exons	 10520 10792

In this case "child" is a normal sequence object containing some source exons and has a parent sequence object called "my_parent". Unusually "my_parent" is its own parent.

Until now if you tried to display "child" as an Fmap using xace, xace would simply hang while displaying the busy cursor and you would have no option but to kill xace.

AceDB does not prevent you from having circular references like this and nor should it. You may have perfectly legitimate reasons for wanting an object to point to itself, or perhaps more likely, you may have a web of objects that if traversed will have loops within the web.

The problem for AceDB is that for some parts of the code this can lead to infinite loops such as when the Fmap code is searching up through a particular Sequence objects parents to find out the final position of that object within the overall sequence in which it is positioned. If the code encounters a parent that points to itself then it will continue to search "up" forever.

The only way to deal with this is make sure the code can detect this occurance and prevent the loop. Most of these places have been fixed now and Fmap itself should now deal with this by stopping at the point of the circularity and trying to display what its got. In most cases the Fmap will display a warning message identifying the object which has the cicular reference in it. The above example was copied (to protect the innocent) from a real example which caused xace to loop endlessly, the bug is now fixed.

If you find other examples of circular references in objects that cause AceDB to crash then please send us mail at acedb@sanger.ac.uk.

### Warning about stack size and very big databases

Recently AceDB crashed repeatedly while Dan Lawson was trying to build the C. elegans database. This turned out to be because the AceDB process was running out of stack space while processing CHROMOSOME_V (about 21 Mbases in size). Our initial approach was to unlimit stack space to the then maximum of 32MB and rerun AceDB, AceDB again crashed for the same reason. We then raised stack space to 52MB and Dan was able to complete the worm build.

There are several things to note here:

- On our machines 32MB of stack size was enough to process the other C. elegans CHROMOSOME_* objects which are about 17 Mbases long.
- CHROMOSOME_V required more than 32MB of stack size, we don't know exactly how much.
- This is a temporary problem only (see below).

AceDB should not be using this much stack space and it does so because a number of routines were written recursively to go up and down object trees in the database. This is a natural way to write such code but can be wasteful of memory. Testing will show which routines are using up the stack space and it should be possible to rewrite them non-recursively so that stack space is not a problem.

In the meantime you should follow this procedure to raise stack size (assuming you use C shell):

Use the limit command to find out what your current stack size limit is:

    > limit stacksize
    stacksize       8192 kbytes
    > limit -h stacksize
    stacksize       32768 kbytes
    >

The first limit command shows what our current stack size limit is, the second shows the maximum it can be raised to. If the current limit is lower than the maximum then use unlimit to raise it to the maximum:

    > unlimit stacksize
    > limit stacksize
    stacksize       32768 kbytes
    >

If your stack size is already at the maximum and you still need it to be increased then you will need to ask your own system support staff to do this as it requires root permission and a possible rebuild of the Unix kernel to do it (!).

## Bugs Fixed

### "Graph Not Found" bug

Sometimes xace crashes with a message that is some variant of "Graph Not Found" or perhaps "could not find FeatureMap on graph". Many of these should now be fixed after a change to the way popup dialogs are displayed, if you still get crashes of this sort, please try and reproduce the crash and let us know by mailing acedb@sanger.ac.uk or raising a problem online at http://www.sanger.ac.uk/cgi-bin/webddts/WebDDTS.pl?Project=Acedb.

### Tree window not redrawn properly

This is the bug that has appeared, been fixed, reappeared and now (hopefully) is fixed. The bug has been very hard to fix because it only affects some of the people some of the time. After a life and death struggle Simon (Kelley) thinks he's fixed this. If not, then you'd better contact us at acedb@sanger.ac.uk.

### DNA dumping bug

There was a bug in the DNA dumping code for databases where some objects used the Sequence class and some the SMAP. The code looked in only one or the other not both. This is now fixed.

### Signal catching menu

The menu item for controlling signal catching (right click on "Admin" button in xace main window) was not correctly updated as signal handling status was changed either interactively by the user or via the "-nosigcatch" command line option. This is now fixed.

### Support for the WWW_location tag broken

The WWW_location tag/data got broken in AceDB 4_9c, this is now fixed and should work as normal.

### Socket server fixed on HP

We have had an HP machine on loan for some weeks to test AceDB on, this has just gone back after several bugs fixed were made to AceDB including:

On HP's, non-blocking reads of a socket return EAGAIN where other systems return EWOULDBLOCK. Unlike most other systems HP has different values for the two error numbers. This meant that AceDB detected what it thought was an error when really the HP code was returning the EWOULDBLOCK return code. Once fixed the socket code worked perfectly.

### Symbolic link missing in source code download file

To build AceDB from the source code requires a symbolic link to wmake/makefile, this link was missing from the source code download file. This is now fixed.

### Misleading Stack size message

Sometimes when AceDB crashes it produces a message about raising your stack space, unfortunately this message was often produced when this would not have solved the problem. The message is now only output if the users stack space is very low, i.e. 1.5 MB or less.

## August monthly build now available.

You can pick up the monthly builds from:

Sanger users
  ~acedb/RELEASE.DEVELOPMENT
External users
  http://www.acedb.org/Software/Downloads/monthly.shtml

## Next User Group Meeting - D319, 2.30pm, Thursday, 16th August 2001

Last modified: Tue Aug 7 10:44:50 BST 2001