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.
Not much to report this month as most of the acedb developers have been away on their holidays and are of course now refreshed to hack away at acedb with renewed vigour.
Porting to other platforms is not easy and although the task of porting acedb to MS Windows is considerably eased by our use of the Cygwin libraries which provide a unix system call interface on a windows machine, its still not all plain sailing.
Recent problems include:
For all this the system generally works very well and means that acedb truly runs on Unix, Mac and MS Windows machines.
Originally the objects that made the hierachy from which FMap constructed its view of a sequence had to all belong to the Sequence class. The introduction of the SMap code into acedb now allows for hierachies to be made up of any objects as long as they contain the SMap tags and data.
While this system is very much more flexible and brings many benefits it has led to some problems in the FMap code. A recent example from the C. elegans database was a bug which meant that if a user double clicked on a "Transcript" class object in the FMap it was not Tree displayed as would normally be expected. This was caused by an assumption in the code that the object should have been of the Sequence class.
While this bug has been fixed it is likely that there will be other areas of FMap that will have to be fixed in the future since much of the code contains often subtle assumptions that objects will be of the Sequence class. This is work in progress so if you run into problems with FMap that you suspect are caused by SMap related changes then please email the acedb developers.
Fixed bug in tree display, lookDraw->stackText must be large enough under all circumstances since it gets passed to graphTextEntry with a buffer length of 2500.
(Simon Kelley srk@sanger.ac.uk wins the "Developers award for Persistence under Fire" for sorting this one out.)
Previous versions of acedb did not pass gap information to blixem, the latest monthly now does this, but.... The process by which acedb passes sequence/clone information to blixem is not straight forward as account must be taken of orientation (e.g. was the sequence reverse complemented in fmap ?), whether blixem is being run as part of xace or as a separate program, what format the gap information should be in and so on and so on. Sadly this has led to a few bugs. Simon has manfully tracked these down and fixed them one by one.
You should now find that gapped alignments from fmap are now correctly displayed in blixem.
Rob has been adding to and improving documentation for the aquila system, see documentation on the website. He has improved the sections on how to add and run tests and how to interpret the results.
You can pick up the monthly builds from: