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 improvements to the "gif smap" commands, to column overlap control in FMap and to EMBL dumping. There are some performance improvements to the socket server and some improvements to SMap, a bug fix and for developers some improvements to the ACEIO package.
The "smap" command available from the the "gif" submenu allows you to map the
coordinates from one sequence into the coordinate frame of another related sequence.
The format of the command is:
smap -coords x1 x2 -from class:object -to class:object
If you do not specify the -to argument it now defaults
to the root of the smap tree containing the -from sequence.
If you do not specify the -coords argument it now defaults
to the start and stop coordinates of the -from sequence.
The different columns in the fmap correspond to the different Method objects in the database, on the forward strand they are given the name of the Method object, on the reverse strand the name is prepended with a "-". Some of the Method object data is shared for both columns, some is column specific. Up until now the overlap mode was shared which meant that if you selected "bump" it would be applied to both forward and reverse strands which could be very irritating as the whole display would be shifted by a large amount to the right. Now overlap mode can be set independently for the forward and reverse strands. The mode is specific to the strand so that if you select "overlap" for the reverse strand, then it will remain as overlap when you for instance reverse complement the display.
(This article is courtesy of Dan Lawson dl1@sanger.ac.uk)
AceDB has the ability to dump a genome sequence in EMBL format. One facet of this code is the addition of /note qualifies for matching EST/mRNA transcript evidence to a CDS feature. AceDB 4.7 checked whether each of the cross-reference EST objects had a Database line with an EMBL accession and would output one of the following:
if the EST has an EMBL accession stored.
/note="cDNA EST EMBL:D72339 comes from this gene"
else the object name is returned.
/note="cDNA EST yk97e6.3 comes from this gene"
AceDB 4.9 no longer performs this check and will always return a note line which use the AceDB object name.
e.g. /note="cDNA EST yk97e6.3 comes from this gene"
This ensures that a curator has control over the transcript name in the EMBL file such that consistency is maintained within the AceDB namespace rather than the EMBL namespace.
A while ago a request was received to add time stamps to each log file message written by the server which seems reasonable. Unfortunately this turned out to be a very bad idea performance-wise since the operation of finding the current time is always very expensive. This simple change had a major impact on server performance, especially where a client issued a whole series of AceDB commands, each one requiring a time stamp !
Having a timestamp for every log message is now optional, the default is to have them only for session start/end messages. In the future an option will be added to allow the server administrator to specify a timestamp per every NN messages.
Socket server performance is now significantly better than the RPC based AceDB 4_7 server.
There was a design problem with sMap: it could not encode strand infomation for single-base mappings.
In addition there was an implementation problem where a mapping with a single-base DNA block as a result of the uncertain strand mapping would sometimes be complemented incorrectly.
The following changes have been made to SMap:
S_Child tag2 100 100 Align 100 1 -1
This takes the same arguments as sMapMap and disambiguates the case
were the output from sMapMap has y1==y2. In the cases where the result
of calling sMapMap is y1!=y2 this function just returns TRUE when
y1>y2 and FALSE otherwise.
These changes fix the one-base mapping and DNA complementing problems.
Fixed bug in code to support xremote calls to fmap routines, the current fmap graph in the display system was not reset correctly after destroying an fmap which is to be replaced by a new one.
If you wish to make comments/suggestions about any of the below, please mail them to acedb@sanger.ac.uk
The AceIn/Out packages could be expensive to use in the case where the caller wanted to replace the text in an existing AceIn/Out object, to do this required destroying the existing object and recreating a new one with the new text. This was expensive for instance in the server where new commands are constantly read in and new replies sent out.
Two new calls have been added which allow replacement of existing text with new text in an existing AceIn or AceOut object. The calls are:
void aceInSetNewText(ACEIN fi, char *text, char *params) ;
void aceOutSetNewStack(ACEOUT fo, Stack s) ;
No monthly build, sorry.