[emboss-dev] Mapping EMBOSS to Ruby, Perl and Python

Pjotr Prins pjotr.public78 at thebird.nl
Tue Dec 1 11:38:35 UTC 2009


Hello, anyone on this list?

Pj.

On Mon, Nov 30, 2009 at 12:57:17PM +0100, Pjotr Prins wrote:
> For your inspection, I have committed a patch for splitting out the
> logic of ./emboss/transeq.c. The patch is here:
> 
>   http://github.com/pjotrp/EMBOSS/commit/713800c4aa08ddf70b87f245a524c1a0b30c0942
> 
> The simplified transeq.c is here:
> 
>   http://github.com/pjotrp/EMBOSS/blob/biolib/emboss/transeq.c
> 
> The new interfaces are here:
> 
>   http://github.com/pjotrp/EMBOSS/blob/biolib/emboss/function/emboss_transeq.c
> 
> Basically I have split out the ACD logic and programming logic and
> given them new names:
> 
>   int transeq_acd(int argc, char **argv)
> 
>   AjPSeqout transeq( AjPSeqall seqall, AjPStr *framelist, AjPStr tablename, AjPRange regions, AjBool trim, AjBool clean, AjBool alternate)
> 
> so you can call either from an external program. The advantage being
> the call interface is exactly the same, whether from the command
> line, the web interface, or directly through a shared linked library.
> 
> What do you think? I propose to (slowly) accept splitting out the
> other routines in this fashion. As it does not interfere with EMBOSS
> it can be done in small steps.
> 
> The file emboss/function/emboss_transeq.c may get some extra
> interfaces - the idea is that is contains nicely named and direct
> methods (unlike the internal 'ajCamelCase' naming conventions). A
> useful one would be a simple one reading frame translation with
> pre-selected translation table (for speed). But more on that later -
> I can also weight-lift that in biolib itself.
> 
> The reason I want to do this here is to prevent duplication of
> functionality at different levels. 
> 
> Pj.
> _______________________________________________
> emboss-dev mailing list
> emboss-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/emboss-dev



More information about the emboss-dev mailing list