ACEDB User Group Newsletter - December 2000

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 announcement of ChickAce, a reminder for Unix users about environment limits and "out of memory" errors from Acedb, major reworking of the Acedb website, quite a number of bug fixes, and a proposal for some new variations of the Rename function.

General News

ChickAce

Martien Groenen emailed to say that he has been setting up an acedb database for the chicken:


From: Martien.Groenen@Alg.VF.WAU.NL

During the last 6 months I have set up ChickAce which now contains almost all 
the mapping information that is available for chicken including the linked 
data such as references (abstracts), sequences, Comparative mapping 
information (human and mouse), primers, SNP's etc.
Currently the database is running satisfactory under Windows in our lab, and 
someone within my group is using the available CGI script to make the database 
available on our website (hopefully running in the beginning of next year). 

In one of the latest newsletters I also saw that URL's are now recognized 
correctly from within AceDb. Can I use that to link data directly to other 
databases that are available through the WWW (e.g. for all genes in ChickAce I 
have also added an extra entry for the Locuslink ID for human and mouse. Can I 
make a direct link with Locuslink?).

Could you add me to the mailing list for the AceDb newsletter (you could also 
mention that an AceDb database for chicken has been set up in wageningen).

Best regards,
Martien

Articles

User Environment Limits and Acedb on Unix

This is a brief reminder about user limits which can cause acedb to crash if they are set too low ( applies to unix not MS-Windows users).

All users who log on to a unix box (whether directly or via a network terminal) have a set of user limits which control the amount of memory/files etc. that they are allowed to use. You can look at these limits using the C shell command "limit":


> limit
cputime         unlimited
filesize        unlimited
datasize        262144 kbytes
stacksize       2048 kbytes
coredumpsize    0 kbytes
memoryuse       505664 kbytes
descriptors     4096 

"datasize" and "stacksize" particularly affect Acedb and can cause it to crash by running out of memory. In the above example "stacksize" is about 2MB which is too low, whereas "datasize" is fine for most uses at about 260MB.

If Acedb crashes unexpectedly with either of these warnings:


"Memory allocation failure when acedb requested NNNNNN bytes,
 acedb has already allocated NNNNNN bytes...."

or

"ABORT : Fatal program fault, signal NN...."

then you should try increasing your limits using the "unlimit" C shell command:


> unlimit stacksize
> unlimit datasize
If this does not fix the problem then report it either using the ddts bug reporting system: or by sending a description of the problem to the acedb developers at:

Acedb Web Pages re-organisation

John Sturdy has been undertaking a major reorganisation of the acedb web pages and download site. If you visit the Acedb website you will see that the front page has changed and will continue to change quite radically until about mid-January.

Of special interest are:

John will be adding a lot of new material to the website over the next couple of weeks and our intention is to make it a lot more usable. Comments or suggestions are welcome, please send them to the Acedb newsgroup or acedb@sanger.ac.uk.

New Features

New position readout in fmap

A small change courtesy of Jean Thierry-Mieg, fmap has a friendlier readout for the position on the sequence which will now be in kilo (kb) and Mega (Mb) bases, making it a little easier to read than 1238749217498123794 as used to be displayed for long sequences.

Better diagnotics from Rename/Alias failures

Previously Acedb has not reported the reason for these failures, only that they happened, now parsing will report in detail the reason for any Rename or Alias failures so that fixing them should be easier.

Bugs Fixed

Colours bug with gifs

GIF images produced by Acedb 4_8c were sometimes in garish/hard to read colours, this is now fixed in the December monthly build.

Dumping objects with very large tag values

Some tag values can be very large (e.g. DNA) and this has caused acedb to overrun one of its internal buffers, this is now fixed with dynamically growing buffers.

File Chooser irritations

Several irritating features of the File Chooser window have been fixed:

Cut/Paste bug fixed

Cut and Paste of larger texts (e.g. DNA) was broken, this was a bug in the underlying Window System software (GTK) and is being fixed by installing updated versions of the software which include the bug fix.

Main Window reset after "Clean Up"

"Clean up" behaviour has been returned to how it was in 4_7, the local/global search is left as it was before the "Clean up".

Socket Server Admin users permissions bug

If you noticed problems with Admin users not having access to some commands for the socket server, this is now fixed. Admin users should have access to all possible commands as they have the highest permission levels.

Education

HGMP are hosting an Acedb course in the week of 22nd-26th January 2001.

The next Sanger Centre course is likely to be in June 2001.

If you are interested in either please mail Sylvia Martinelli (sylvia@sanger.ac.uk)

Future Plans

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

Revised INSTALL script for Acedb

The current INSTALL script for acedb is being revised, the section for installing the worm database will be moved into a separate script (available from the worm web site in the January). The download site will include for each acedb release the following archives: compilable source code, binaries for selected platforms, help pages, docs and a test database.

Enhancements to "Rename"

Discussions with a number of users have suggested that the "Rename" operation doesn't always so what they would like or expect. Currently it works like this:

Let's say we wish to rename Sequence object "A" to "B":

If the database does not contain a Sequence object with the name "B", the operation is straight forward: object "A" is simply given the new name of "B" and the name "A" ceases to exist.

If the database does contains a Sequence object with the name "B", things are more complicated, the two objects are combined to form a new "B" object following these rules:


                                                    value used for
tag type   tag in "A" ?    tag in "B" ?             tag in new "B"
--------   ------------    ------------             --------------
UNIQ           Y               N                      "A"s value
               N               Y                      "B"s value
               Y               Y                      "A"s value

non-UNIQ       Y               N                      "A"s values
               N               Y                      "B"s values
               Y               Y                   (all of "A"s values
                                                   + all of "B"s values)

In this case the original "A" and "B" objects will be replaced with the single new "B" object.

The new proposal is:

Given that we want to rename object "A" to "B" and that "B" already points to an object:

  1. The existing rename operation will combine "A" and "B" as before.
  2. New variants of rename will be provided: When implemented, the third and fourth operations will probably be called "Merge-nnn".

This would allow users to do renames and choose how this should work. They could for instance do a "safe-rename" which would avoid any loss of data, or conversely do a "replace-rename" which would avoid any combining of objects.

A question remains about whether these operations should be inclusive or exclusive for non-UNIQ tags, i.e. should they be combined as before, or should one set of tags overwrite another. If you are regularly parsing in data to an Acedb database and have thoughts about how you would like Rename to work, then please mail acedb@sanger.ac.uk.

December monthly build available in first week of January 2001

Sorry, not time to do this before Christmas, build has been done and will be distributed first week in January.

You can pick up the monthly builds from:

Sanger users
~acedb/RELEASE.DEVELOPMENT
External users
ftp://ftp.sanger.ac.uk/pub/acedb/Sanger-release.2000_12_22.tar.gz

Next User Group Meeting - D319, 2.30pm, Thursday 18th January 2001



Ed Griffiths <edgrif@sanger.ac.uk>
Last modified: Mon May 21 15:38:36 BST 2001