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.
AceDB 4_9 finally arrived and needless to say there have been some bugs, to fix these we've just released AceDB 4_9b. There is a new scrolling message window to replace the millions of popup dialogs that AceDB sometimes produces. There's a new version of AcePython and an article on GFF.
This update of AceDB 4_9 contains a number of fixes and new features covered in the rest of the newsletter. The main purpose of the release is to fix a number of bugs in the new code.
Both the Monthly and Public AceDB downloads pages have been updated with the new build. Internally to the Sanger Centre the build can be obtained from ~acedb/RELEASE.SUPPORTED.
Well the big names in computing are beating a path to our door. In the March newsletter I reported that HP had offered us a loan machine and are keen for AceDB to be ported to their new Intel 64-bit machines (when they arrive). Well now IBM have made contact to say they want AceDB on their machines as well.
"Fame" at last, well something like that anyway.
In last months item on "Non-numeric tag names" I should have emphasised that the valid character set for tag names does not include the dash character "-" which is used in the query language to mean "subtraction". There are certainly databases in the Sanger Centre that use tag names that include the "-" character and these tag names will need to be changed.
Please note also that the "tag names" are the text that appears in your models.wrm file, not the data in your database which is allowed to have this and many other characters !
Starting this month, if you use the "-version" flag when running
an AceDB program it will output the original build directory which will show
exactly which months code you are running:
griffin[edgrif]42: xace -version
ACEDB 4_9a, build dir: RELEASE.2001_06_30, compiled on: Jul 2 2001 10:22:19
In this case the June build for 2001.
From now on, as a short cut when you make a new "temp_gene", the Species
and From_laboratory
tag values (if they exist) will be copied from the parent Sequence object.
Normally in AceDB informational and error messages are displayed individually in so-called "popup" dialog windows which require the user to click on an "OK" or "Continue" button to get rid of the window. For the odd message this is acceptable, but if there are a large number of messages (as when there are DNA mismatches) this becomes irritating in the extreme.
A partial fix to this problem was made for DNA mismatches by allowing an xace user to interactively turn off reporting of them ( see February, 2001 newsletter). This did not solve the problem for other frequent messages however.
A new "message list" facility has been added to xace to deal with this problem. The new code allows the user to choose between having errors reported in the usual way or instead having a single "message list" window which will display a rolling list of informational/error messages as they are generated. The messages do not need to be replied to, they are displayed in the window and the window is raised above other AceDB windows to alert the user that a message has arrived.
To configure "message list" click on "Admin.." on the main window and then select "Preferences" from the "Admin.." menu list. This will show the "Preferences Editor" window from which you can set:
USE_MSG_LIST
MAX_MSG_LIST_LENGTH
N.B. You should note that for any preferences where you have to
type a value, you must press the return key
before you click the "Apply" or "Save" buttons. If you don't do this, the
value you have entered will be ignored.
Once you have selected USE_MSG_LIST and clicked
the "Apply" or "Save" buttons, a new window with the title
"AceDB Normal/Error Messages" will appear. The window has scroll bars
so that you can adjust it to the size you want and also scroll through
messages.
If there are no messages then the window will show
"< No messages currently >"
As messages arrive they are displayed with the newest at the bottom displayed in
red, older messages are scrolled off the top. Once the list has reached
MAX_MSG_LIST_LENGTH in size, older messages are discarded to be replaced
by new ones. Each message is shown with
a time stamp so that you can see when it was generated. You will see something
like this:
2001-06-14_16:35:30: Roger, your sequence is mismatched ! 2001-06-14_16:35:31: Roger, your sequence is still mismatched ! 2001-06-14_16:35:32: Use AceDB and all your troubles will be over ! 2001-06-14_16:35:33: Sorry, my graph has disappeared !
There is online help available from the popup menu for the message list window.
To make this available, the database administrator will need to update
the whelp/ subdirectory with the
MesgList.html help file from the whelp/
directory in the acedb 4_9b release.
If you prefer to use the individual popup message windows and only switch to the scrolling window occasionally, you can do this because informational/error message windows will now be displayed with an extra button which can be used to switch to popup windows. Just toggle on the "Switch to Message Window" button and click the "Continue" button.
For those of you who don't know Python, it's a freely available, object oriented scripting language. Unlike Perl, Python was object oriented from the start and is a much cleaner implementation of objects, it has a large standard library, GUI code etc. etc.
Siegfried Schloissnig and Thomas Sean Powell originally wrote an interface to the AceDB socket server in Python while attending the AceDB2000 workshop in Vancouver. Siegfried has just sent us the latest code and this announcement:
AcePython:
AcePython provides a basic Python based interface to the AceDB database. Currently only socket based connections are supported (we are not planning to support the old RPC based server).
AcePython resembles the AcePerl interface, so it is easier to use for people with AcePerl experience.
Basically the first step is to open a database connection using Ace.connect. This returns an object representing the database connection. After a connection has been established it can be used to retrieve objects from the database with the fetch method.
The fetch method uses the underlying transport mechanism to send a query to the server (as mentioned above, only socket based connections are currently supported). The result of the query is passed to the parser, (a C implementation is coming soon) which returns one or multiple AceObjects.
AceObjects support various methods to extract data. These methods are named analogous to their AcePerl counterparts.
Right now there is no support for manipulating or inserting data into AceDB.
Feel free to contact the author, Siegfried Schloissnig, at schloissnig@mpi-cbg.de or via normal mail: Computer Department, Max Planck Institute of Molecular Cell Biology and Genetics, Dresden.
(This article is courtesy of Keith Bradnam krb@sanger.ac.uk)
Many AceDB database curators are (necessarily) familiar with dumping data from their databases. The most common option for dumping is probably the exporting of sequence information (DNA or protein). This can be done from a keyset list of sequence objects (i.e. click on the 'Export...' menu) or by right clicking on the fmap displays (i.e. the graphical views of sequences).
These methods allow you to quickly export sequence information in either the native AceDB format ('ace' format) or as a FASTA formatted sequence file.
Perhaps not so well-known is the option of exporting sequence information in the General Feature Format (GFF). The GFF format allows for a simple (but powerful) description of all sequence features in a format which is ideal for parsing by simple shell/perl scripts. This is also a format that is used widely in the bioinformatics community, and thus is useful as a convenient data-exchange format.
This can be particularly useful if you simply want to grab a snapshot of what BLAST hits a particular sequence contains, or where the predicted exons of a coding sequence are.
To export GFF features, view your sequence graphically using the fmap display and then select the right-click menu option named 'Export Features'. This will then allow you to save to a *.gff file. Remember that only those features that are contained within the current 'active zone' will be exported, so you may wish to first restrict/broaden the active zone.
A complete description of the GFF format is available at:
Sad to say, yours truly introduced a bug into fmap while trying to fix another bug. The bug manifested itself by xace reporting that objects were off the end of the DNA sequence. While this was correct, the code then did not produce the fmap sequence correctly causing AceDB to crash frequently.
This should now be fixed, if its not you can send stern emails to Ed Griffiths <edgrif@sanger.ac.uk>.
Some users were finding that gmap crashed on being redisplayed, this is now fixed.
Thanks to Stewart Morris of Medical Genetics Section, The University of Edinburgh (<Stewart.Morris@ed.ac.uk> for fixing this one. A simple typo. resulted in the wrong operating system file being examined for printers that are NIS defined rather than being locally defined on the users machine.
Several other bugs in printing were also fixed:
Occasionally the following sequence of errors happens with AceDB:
DATABASE: /nfs/disk59/scanner/fpc/ACE/mousedb LOGFILE LINE
:5094:2001-06-18_01:31:28 fes22 21401 FATAL ERROR reported by program tace, in
file disknew.c, at line 866: diskblockwrite can't open blocks
/nfs/humdata1/humace/databases/mousedb/database/block8.wrm (system error 13 -
Permission denied)
DATABASE: /nfs/disk59/scanner/fpc/ACE/mousedb LOGFILE LINE
:5209:2001-06-18_09:14:13 hgs1g 24875 FATAL ERROR reported by program tace, in
file disknew.c, at line 866: diskblockwrite can't open blocks
/nfs/humdata1/humace/databases/mousedb/database/block9.wrm (system error 13 -
Permission denied)
DATABASE: /nfs/disk59/scanner/fpc/ACE/mousedb LOGFILE LINE
:5220:2001-06-18_10:00:34 hgs1g 28578 FATAL ERROR reported by program tace, in
file disknew.c, at line 578: Duplication in fuseBats
What has happened here is that a user has been allowed to get write access
to a database, made some changes but then when they come to save the changes it
turns out that some of the database/blockN.wrm files are owned by another user
and so only part of the changes get saved. This results in the database becoming
corrupted.
While its possible to set the permissions of the database directories and
the AceDB programs to prevent this happening it also points to a bug in AceDB.
AceDB should check that it can read/write all of the database/blockN.wrm
files before allowing the user to have write access.
The code now does this with the result that you may notice that you are refused
write access more often. You may also notice that even though you could get write
access when first started up xace, you may subsequently not be able to save because
some database/blockN.wrm files have changed ownership while you have been
working. This seems preferable to having the database get corrupted.
If you have trouble getting write access you should check the database/log.wrm
file for error messages (look for your userid near the bottom of the file) to see
if access to database/blockN.wrm files is the problem.
This item only affects users who do their own builds/compiles of the server/client AceDB programs on Compaq (formerly DEC) Alpha Stations.
From time to time computer manufacturers change system header files which sometimes
messes up AceDB builds. There has been a change in the Compaq Alpha operating system
header /usr/include/sys/socket.h which causes the AceDB build to fail.
Use the "uname" command to find out what level your Alpha operating system
is at:
> uname -a
OSF1 your_system_name V4.0 1229 alpha
If your system has an update level that is smaller than "1229" then you don't need to worry about this further. If the update level is "1229" or higher then read on.
Have a look in /usr/include/sys/socket.h to see if it contains the lines:
#ifdef _POSIX_PII_SOCKET
typedef unsigned long socklen_t; /* 64-bits */
#endif
If it does then you should do your builds of the server/client programs like this:
make USEROPTS='-D_POSIX_PII_SOCKET' saceserver sgifaceserver saceclient
If you have any problems with this then please mail acedb@sanger.ac.uk.
If you wish to make comments/suggestions about any of the below, please mail them to acedb@sanger.ac.uk
If you are doing some programming using the Graph package then you may want to make use of the NULL_GRAPH enum which I've just added to graph.h. This is an enum which has the value 0 (successive graphs are numbered incrementally from 1 so no graph ever has the value 0) and has the advantage that debuggers display it symbolically as well as making the code more readable for newcomers.
xace allows the user to set personal preferences which are recorded in the file
$HOME/.acedbrc, while doing the work for the message window
I added callback functions so that its possible to have a function executed elsewhere
in the code when the user sets a preference.
NOTE that this build is the acedb 4_9b build.
You can pick up the monthly builds from: