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 is the post-Christmas/not that much has changed report. There are small but important changes to the acedb database log format, a short article about the introduction of better web-based downloads for acedb and a number of bug fixes.
A number of users didn't see last months newsletter and wanted to know how to go directly to a directory using the 4_8c file chooser. I'll just repeat last months item about how to do this:
The acedb locking/write access mechanism now works on Windows 95/98.
When an internal error happens in acedb or the system runs out of resources (e.g. program stack space), the operating system may send a "signal" to acedb which stops the program from running. When this happens acedb runs a special signal handling routine which attempts to terminate the acedb program with a message about what has happened.
The message that acedb outputs has been improved in the following ways:
So if one of the acedb programs you are using exits with a message like this:
// ABORT : Fatal error, program received signal....
and you can remember/reproduce the sequence of actions that caused it then please
get in touch with the acedb developers
(acedb@sanger.ac.uk).
Due to popular demand, the "preserve" button has been added back for the tree window display, selecting this item on a tree window menu will ensure that the window stays around until explicitly "quit".
Its possible to download acedb code in one of two ways:
We've introduced the web pages to make it easier to navigate the acedb downloads directories and get the download package you want. On visiting http://www.acedb.org/Software/Downloads/ you will find there are three levels of code you can download and a quick summary of the current build status available at the bottom of the page.
The three levels of code that can be downloaded are:
If you visit the page for one of these levels of code you will see that there are various packages that can be downloaded ranging from the source code, to precompiled binaries for various platforms to a demonstration database. If you find any problems with any aspect of the download pages then please let the acedb developers know.
Drawing of some fmap/gmap displays was very slow because a bug in the acedb code was causing the displays to be drawn twice. This should now be fixed for all acedb displays, please email the acedb developers if this is not so in the latest monthly build code.
A another smaller bug was that gmap code would try to map loci or regions even if they had no given map coordinates, this has also been fixed. In this case the loci/regions are displayed in a text window.
Where a simple rename of an object was done via parsing an acefile, the object was not left in the active keyset. Now the renamed object will be in the active keyset allowing a quick check of renames.
database/log.wrm
Logging information in acedb was not complete because although the start of a new user session was recorded, the end of the session was not. This meant that if acedb failed in a way that could not be caught by the error handling routines, there was no record in the log that this had happened.
Now all session starts/ends shouid be bracketed by:
<date/time> <machine> <process> SESSION_START - <user/program details>
<date/time> <machine> <process> session information
<date/time> <machine> <process> SESSION_END - <session end type>
where "session end type"
can be one of:
NORMAL EXIT
ABNORMAL EXIT
CRASH
If a SESSION_START
is found in the log without a corresponding
SESSION_END
, this means (assuming the acedb program is no longer running)
that acedb crashed severely in a way
that it could not detect (e.g. if the program was killed with "kill -9" or on some
systems if it ran out of stack space). This type of crash may have left the database
corrupted if the program crashed while updating the database,
and certainly if the database does become corrupted you should look
in the log for either a SESSION_END - CRASH
or an unmatched
SESSION_START
.
Note that a little care is required in parsing the log file for these paired
starts and ends, process ids can be reused by the operating system. This means
that you need to first find the "SESSION_START/machine/process_id"
and then
look for both a new "SESSION_START/machine/same_process_id"
and
a "SESSION_END/machine/process_id"
. If you find the former, or don't
find the latter it means the acedb program crashed severely.
You can pick up the monthly builds from:
!*! Please note changed venue !*!