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.
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
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:
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.
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.
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.
GIF images produced by Acedb 4_8c were sometimes in garish/hard to read colours, this is now fixed in the December monthly build.
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.
Several irritating features of the File Chooser window have been 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.
"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".
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.
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)
If you wish to make suggestions about any of the below, please mail them to acedb@sanger.ac.uk
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.
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:
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.
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: