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 first contributions from acedb users to the newsletters, thanks to Keith Bradnam and Dan Lawson. There are a number of important bug fixes which in particular affect people who use the giface code to produce gif versions of fmap etc. Hewlett Packard have contacted the AceDB developers as they would like AceDB to be part of their IA-64 program.
Previously you could only export the cDNA for a sequence object if that object was marked as a CDS. In a rigorous way this makes sense but can be irritating if you have an object for which you'd just like to take a quick look at the cDNA. This restriction has now been removed so that, provided the object is in some way "attached" to some DNA, you can export a cDNA for it. It is of course up to you to interpret what that DNA might mean (!).
AceDB log files can grow very quickly and up until now a new log file was only started if the database was reinitialised, or if the existing log file was moved aside manually. This is not very convenient, particularly when running an acedb server on a database.
Support has been added to start a new log using the following methods:
tace/giface
sace/sgiface-server
You can also send the server a
SIGHUP signal which has the same effect, but note that if you use this method,
the new logs will not be started until the next record is written to the relevant
log.
This article was kindly supplied by Dan Lawson <dl1@sanger.ac.uk>, he wins a beer for being the second voluntary contributor to the newsletter.
The way in which objects are displayed in the F-map display is defined by the Method class. The Method object contains information such as the colour and column priority for the drawing of the F-map. The Method object also contains GFF definitions for the labelling of the GFF dumps of an object.
Recently in the worm database we have extended the use of the ?Method tag in the Sequence class to be bi-functional. The tag continues to point to a Method object for drawing the F-map but is also used in the generation of subclasses (similar to using a standard type tag in the Properties e.g. Genomic_canonical or CDS.) An example of a new Method is 'Link' which indicates more explicitly which Sequence objects are link objects - i.e. those which contain the golden path for a group of overlapping genome sequences.
As every Sequence will have a Method the xace code will attempt to display the object in the F-map. If the Method object does not contain colour/column priority information then the default blue box with a low column priority will be displayed. Some types of objects should not be displayed in the F-map (the Link objects are a good example), and so we have introduced a new tag into the Method class. If you set this tag then all objects using the Method will not be drawn. The tag is called 'No_display' and should be set as part of the general Method descriptions.
The above modifications allow features to be dumped to GFF
files with sensible definitions without cluttering the F-map
view of a genomic region. If you have any queries regarding
these changes please contact
Daniel Lawson <dl1@sanger.ac.uk>.
Articles
Hewlett Packard have recently ported AceDB to their latest machines/operating system versions and are keen for AceDB to be part of their "Developers Program" for their new range of IA-64 based machines. The IA-64 is Intels 64-bit CPU chip and is being used by HP for some of their new machines. We should be receiving an HP test machine within the next few weeks.
This article was kindly supplied by Keith Bradnam <keith@thale.life.nottingham.ac.uk>, he wins a beer for being the first voluntary contributor to the newsletter.
Whilst the quest for the legendary 'Golden Manual of Ace' continues, mere mortals will have to content themselves with picking up tips and second-hand rumours from the unchartered back-waters of the internet.
The sometimes-annoying truth is that many useful Acedb features remain undocumented. But maybe we (the Acedb community) can help to change that. I'll make a start by revealing a couple of useful Acedb features that I (accidentally) discovered after browsing the ACeDB (worm) database one day.
It is not always easy to draw attention to tiny features that are present on very large sequences. E.g. a 50 bp BLAST homology object which is present on a 200 kb sequence object appears as a narrow black line.
It would also be useful if you could draw attention to a feature by displaying it in another way, e.g. as an arrow which points to a particular range of bases (or even a single nucleotide). Well, the good news is that you can. The trick is to create 'Allele' tags within a sequence object.
Such tags allow you to create an arrow-like object which appears in the 'Alleles' column of the sequence display. Arrows can have a 'direction' (up or down) as they are accompanied by a smaller, side arrow. They can also have some associated text which appears on the sequence display.
E.g. consider the following ace file:
Sequence : "EMBL:A47152"
Allele "Test1" 50 100 "Message1"
Allele "Test2" 400 300 "Message 2"
Allele "Test3" 1000 1000 "Message 3"
This file (when read into an appropriate database) will create three arrows that appear on the sequence display for 'EMBL:A47152'. The first arrow points to a region of 50 bp (between coordinates 50 and 100) and will display the accompanying message. Because the second coordinate is larger than the first, the arrow appears with the smaller side arrow pointing downwards.
The second object displays an arrow which will point in the the up direction (first coordinate larger than the second). The third arrow will also point upwards but corresponds to a single nucleotide in the sequence.
If you zoom in on these arrows they will eventually transform into 'open rectangles' (a bit like a ']'). The point at which an arrow turns into an open rectangle depends on how large a region the Allele tag corresponds to.
If all this sounds a bit confusing, look at these examples which were created to show the positions of insertion events (note that AceBrowser displays the arrows a little bit differently from xace):
http://ukcrop.net/perl/ace/pic/AGR?name=EMBL%3AAB018109&class=Sequence
http://wormbase.sanger.ac.uk/perl/ace/elegans/misc/epic?name=T21F2&class=Sequence
Apart from the above example, sequence displays don't usually display any text. Sometimes it would be useful to display a gene name or gene function (where known) next to a coding sequence on a sequence display.
To add text information, simply add a line that reads 'Show_text' to the 'Coding' Method object, e.g. your Method object should looks something like:
Coding Display Colour BLUE
Frame_sensitive
Strand_sensitive Show_up_strand
Overlap_mode Bumpable
Width 2
Right_priority 2
Show_text
Blastn
Blixem Blixem_X
Blixem_N
The rules governing what text is displayed seem hard to determine but contents of 'Remark', 'Gene_name', 'Gene_function' tags always seem to be displayed. In AceBrowser, these don't always work as stable links when clicked apon.
Both these examples are heavily used in the Arabidopsis Genome Resource (AGR) at http://ukcrop.net/agr
Several people reported that when they tried to print something from AceDB, the list of printers in the print window contained large numbers of blank/unusable buttons which made the print window unusable. This problem was caused by System Support inadvertantly changing the format of the system file /etc/printcap which contains the list of printers available. The change in format meant that acedb no longer correctly parsed the printer names, hence the blank buttons. The file has now been returned to its previous (unix standard) format and the print window should now work correctly.
When using fmap, displaying the cDNA for a gene resulted in the silent creation of a DNA object for the cDNA. If, after you did this, you did a save, the cDNA object would also be saved into the database. Over time this gradually clutters up the database with redundant and unwanted objects. fmap has now been changed so that the cDNA objects are removed when the fmap displaying the cDNA is destroyed (e.g. by using the "quit" item from the main menu).
If you reused an fmap window to display an object that you clicked on from the tree window, in some circumstances the title did not get updated to the name of the new object in 4_8. This is now fixed.
The help code in AceDB crashed for some cases where it could not find the help files, this is now fixed.
When using the "gif" submenu from giface or sgifaceserver, it is possible to set the size of the virtual graph using the "dimensions" option. In cleaning up the virtual graph code a bug was introduced which meant that when the dimensions option was used the graph produced would be very small which resulted in the code looping and consuming memory until it crashed or simply producing a graph of zero size. This is now fixed.
As part of the clean up of the virtual graph system used to produce gif versions of AceDB windows, a bug was introduced which resulted in AceDB gradually using up memory because any data associated with the graph was not freed correctly. The error was in gifcommand.c, which used the test aceInIsInteractive() to decide whether to set isGifDisplay to TRUE. This always fails because command.c (which calls gifcommand.c) always copies the terminals input into a text string, this is by definition non-interactive ! In addition to this, this test will always fail for the server where no input is ever interactive. The fix was to initialise isGifDisplay to FALSE, but it's then set to TRUE by the main()s for giface and sgifaceserver, this then ensures that sequence and display stuff is freed correctly.
You can pick up the monthly builds from:
!*! Please note changed venue !*!