Genetic codes and other repeated ACD

Guy Bottu gbottu at ben.vub.ac.be
Wed Apr 13 13:22:12 UTC 2005


	Dear Peter, dear all,

Allow me to add something to the recent discussion about geneticcodes. I 
talked about it with Marc Colet, developer of wEMBOSS, and he considers, 
for the sake of GUI maintenance, that it is better to avoid making the ACD 
syntax too complicated and certainly to avoid making too often a change.
A few ideas :

- Currently emboss.defaults does not contain items that are absolutely 
needed. We think it is better not to change that philosophy by putting 
e.g. the geneticcodes in it. It could however be an idea to put in 
emboss.defaults a list of databanks in BLAST format, for the sake of BLAST 
wrappers.

- For items like reading frames and maybe geneticcodes, that appear over 
and over again in several ACD files, yet are not user or installation 
customizable, the best proposal among those made in this discussion list 
seems to me to have it defined in one central file, for the purpose of the 
software developement, but to "acdpretty" it into the ACD files before 
they are distributed, for the sake of GUI functioning.

- There is the case of items where users can choose to use their own data 
instead of the EMBOSS distribution data, like symbol comparison matrices 
and codon usage tables (would genetic codes fall into this catagory ?). 
Till now there was each time a new ACD object type defined, like matrix 
and cfile. Is shifting to the use of "knowntype" a good idea ? I do not 
know, but, let's keep consistent.

- There is the issue of the program embossdata, useful for the advanced 
user and a possible tool for displaying choice lists in GUI's. Currently, 
when we run it at the BEN site with just the parameter -showall it produces a 
monstruous long list, because all the databanks (including CUTG) have been 
downloaded and "extracted". Maybe let it by default display only the data 
files in the main data directory ? Note that e.g. the list of PRINTS files 
is anyway not very interesting, since you cannot do anything with them as 
such. Could it be modified so that you can easily get a list of the 
alternative data files used by a particular program (or could a library 
routine called by the program itself do that) ?
 
	Sincerely,
	Guy Bottu,
	BEN




More information about the emboss-dev mailing list